Hallo.
Ich möchte hier die Module zum Senden und Empfangen mittels pilight vorstellen.
pilight_ctrl: - Basismodul für die Kommunikation
define <name> pilight_ctrl <host:port> [api]
- host - IP wo der pilight-daemon läuft
- port - Port des pilight-daemon
- api - pilight version optional, 5.0 oder 6.0 - default 6.0
pilight_switch: - Repräsentation eines Schalters
define <name> pilight_switch <protocol> <id> <unit>
- protocol - Protokoll z.B. kaku_switch
- id - ID oder Systemcode je nach Protokoll
- unit - unit, unitcode oder programcode je nach Protokoll
pilight_dimmer: - Repräsentation eines Dimmers
define <name> pilight_dimmer <protocol> <id> <unit>
Parameter wie beim Schalter.
pilight_temp: - Repräsentation eines Temperatur- und Luftfeuchtigkeitssensors bzw. Wetterstation
define <name> pilight_temp <protocol> <id>
Bei GPIO Sensoren muss als id der GPIO-Pin angegeben werden.
pilight_raw: - Modul zum Senden von raw codes
define <name> pilight_raw
Weitere Dokumentation in den Modulen selbst.
Wichtig ist noch das Attribut "brands" in pilight_ctrl.
Damit wird das Problem gelöst, dass pilight für ein und das selbe Protokoll (für Senden und Empfangen) unterschiedliche Namen verwendet (z.B. arctech, kaku, intertechno).
Beispiel:
Senden mit Protokoll kaku_switch_old, Empfang für das gleiche Device mit arctech_switch_old.
Dann muss arctech durch kaku ersetzt werden. Das erreicht man mit brands arctech:kaku.
Ich habe Einiges getestet und bei mir läuft es aktuell mit drei Intertechno Schaltern und einem Intertechno Dimmer soweit stabil.
Leider habe ich nicht so viel unterschiedliche Hardware - also keine Garantie, dass es mit allen Protokollen (schon) funktioniert.
Die in 6.0 eingeführten Kontakte können als Schalter "umgebogen" werden. Attribut "ContactAsSwitch" in pilight_ctrl.
Viel Spaß.
History:
16.03.15 FIX ID alphanumerisch
20.03.15 NEW Protokoll 'clerverwatts' hinzugefügt
26.03.15 NEW Protokoll 'clerverwatts' unit all für 'all'-Signal
29.03.15 NEW Temperatur- und Luftfeuchtigkeitssensoren
30.03.15 NEW GPIO - Temperatur- und Luftfeuchtigkeitssensoren
30.03.15 NEW Komplette Protokolle ignorieren mit Attribut ignore <protokoll_name>:*
09.04.15 FIX Nur Senden, wenn auch eine Verbindung zum pilight-daemon besteht
12.04.15 FIX Protokoll 'intertechno_old' hinzugefügt
17.04.15 FIX Kleinere Rechtschreibfehler - Danke an pattex
17.04.15 FIX Senden mehrerer Befehle in kurzer Zeit (Aufbau einer Messagequeue)
29.04.15 CHG Attribut ignore zu ignoreProtocol umbenannt, da ignore bereits vergeben ist
09.05.15 NEW ignoreProtocol * - es wird bis auf die durch Submodule definierten Protokoll-ID-Kombinationen alles andere ignoriert
09.05.15 NEW Protokoll quigg_gt* (z.B. quigg_gt7000) ergänzt
16.05 15 NEW pilight_temp: Status der Batterie als reading, Attribut 'corrTemp' zur Korrektur der Temperatur
17.05.15 NEW pilight_temp: Attribut 'corrHumidity' zur Korrektur der Luftfeuchte
20.05.15 NEW pilight_dimmer: Möglichkeit den Dimmer mit der Screen Funktionalität (up|down) zu erweitern
30.05.15 FIX pilight_dimmer: Funktionalität (up|down) + set dimlevel 0
30.05.15 FIX pilight_switch|dimmer: Trigger|Notify wurde immer zweimal ausgelöst
07.06.15 FIX pilight_ctrl: set reset - Verbindung zu Submodulen wurde unterbrochen
20.06.15 NEW pilight_ctrl: set disconnect - Verbindung trennen und nicht automatisch wieder aufbauen
23.06.15 NEW pilight_ctrl: Attribut SendTimeout - Abbruchzeit für Sendebefehl - Default 1s
23.06.15 FIX pilight_ctrl: Sendequeue bei reset leeren
21.07.15 NEW pilight_raw: Modul zum Sende von raw codes
27.07.15 NEW pilight_dimmer|switch|raw: SetExtensions(on-for-timer, off-for-timer,etc)
30.08.15 NEW pilight_temp: Luftdruck, Windrichtung, Windgeschwindigkeit, Windböe (falls von Sensor unterstützt)
06.09.15 FIX pilight_temp: pressure, windavg, winddir, windgust from weather stations without temperature
29.11.15 NEW pilight_temp: add attributes offsetTemp and offsetHumidity to correct temperature and humidity
17.12.15 NEW 30_pilight_xyz: IO-Device über Attribut verstellen
20.03.16 FIX pilight_ctrl: send delimiter to signal end of stream if length of data > 1024 (e.q. long raw codes)
28.03.16 NEW pilight_switch: protocol daycom
02.06.16 NEW pilight_ctrl: protocol oregon_21
03.07.16 NEW pilight_smoke: new module - representation of a pilight smoke detector
13.11.16 NEW pilight_contact: Neues Modul für Kontaksensoren
Module ab 26.04.15 in FHEM integriert und per update erhältlich
Hi,
ich bin neu bei FHEM und heb ein paar Fragen zum Pilight addin:
Muss das attr brand genauso lauten wie das Protokoll oder was ist als brand anzugeben?
Bei mir z.B ist für einen Switch mit Clarus Protokoll als brand clarus oder clarus_switch anzugeben?
Ich habe inzwischen die Brand-Bezeichnung in den Protokollbeschreibungen von Pilight gefunden in meinem Fall "Clarus" Ist eine Brand-definition bei nur einem Protokoll ohne Alternativen notwendig?
Weiters wechselt bei mir die Stateanzeige des Switches beim Schalten nicht, er bleibt auf "defined". Woran kann das liegen?
Außerdem bekomme ich im Eventmonitor beim Schalten mit der Fernbedienung die Meldung pilight_ctrl <name> UNKNOWNCODE SWITCH clarus_switch <id> <unit> <on|off>
Hängt die fehlende Statusanzeige vielleicht damit zusammen?
Schalten kann ich den Switch über FHEM perfekt
Danke
chipmunk
Hallo chipmunk,
es sieht für mich so aus, als wenn du keinen Switch mit dem Protokoll clarus_switch und den richtigen ID's definiert hast?
Mit welchem Modul sendest du denn - vermutlich mit "pilight" und nicht "pilight_switch".
Du könntest mir mal die Definitionen für pilight_ctrl und pilight_switch zeigen.
Hilfreich wäre auch, wenn du verbose von pilight_ctrl und pilight_switch mal auf 5 stellst.
Risiko.
Hallo Risiko
Erstmal Danke für die Antwort
Ich bin derzeit nicht zu Hause., ich werde die Daten am Sonntag abfragen.
Allerdings kann ich zwei Dinge gleich klarstellen:
Ich verwende pilight_switch und das Schalten damit geht einwandfrei, nur die Statusrückmeldung funktioniert nicht.
Der Status bleibt immer auf defined.
Danke
Chipmunk
Hi chipmunk,
damit haben wir das mit dem Modul geklärt ;)
Die Fernbedienung sendet scheinbar mit Protokoll clarus_switch id unit - oder wird da schon was umgebogen?
Der Status wird an alle Schalter weiter gereicht. Da sich kein Schalter für die Message zuständig fühlt, kommt die Meldung "Unknown code...".
Wichtig ist, wie du den Schalter definiert hast. Protokoll, ID und Unit müssen überein stimmen.
Für Clarus gibt es laut pilight Doku http://wiki.pilight.org/doku.php/clarus_v6_0 keine weiteren Bezeichnungen.
Vielleicht sehe ich in den Log's dann mehr.
Risiko.
Hi Risiko,
tolle Arbeit! Ich bin Einsteiger im Thema FHEM & Raspberry, deswegen habe ich auch einige Zeit benötigt, meine ELRO-Fernbedienung über den GPIO-Funkempfänger auszulesen.
Aber nun hat es geklappt!
Daher poste ich hier mal meine Config-Einstellung - vielleicht hilft es anderen etwas schneller zur Lösug zu kommen, als ich ;-)
Zum üben, schalte ich quasi mit der Taste D der Fernbedinung die Tasten A und B hintereinander.
Macht so natürlich wenig Sinn - aber es soll ja nur ein Beispiel sein, wie es klappt.
Umfangreichere Funktionen kommen als nächstes.
# ELRO Fernbedienung
define Fernbedienung pilight_ctrl localhost:5000
attr Fernbedienung brands elro
attr Fernbedienung icon access_keypad_2
# ELRO Funksteckdosen 2A
define LampeMonitor pilight_switch elro_800_switch 13 1
attr LampeMonitor group Steckdosen
attr LampeMonitor room Dachboden
# ELRO Funksteckdosen 2B
define LampeTisch pilight_switch elro_800_switch 13 2
attr LampeTisch group Steckdosen
attr LampeTisch room Dachboden
# Reaktion auf Tastendruck der Fernbedienung
define Fernbedienung2D pilight_switch elro_800_switch 13 8
define Fernbedienung2D_on notify Fernbedienung2D:on set LampeMonitor on;;set LampeTisch on
define Fernbedienung2D_off notify Fernbedienung2D:off set LampeMonitor off;;set LampeTisch off
Noch mal vielen Dank für das Modul!
hmm, jetzt habe ich leider festgestellt, dass ich ein neues Problem habe. ich bekomme pilight-receive auf dem Pi nicht mehr gestartet. Vermutlich, weil ich in Pilight port=5000 gesetzt habe.
ich bekomme nun diese Fehlermeldung:
pilight-receive: ERROR: no pilight ssdp connections found
Aber von fhem funktioniert pilight noch.
kann ich irgendwie in pilight-receive definieren, dass der pilight-deamon auf port 5000 läuft?
Hallo shiiva,
das hat definitiv nichts mit dem Port zu tun.
Bei mir lauft der pilight-daemon auch auf 5000 und ich kann pilight-receive parallel betreiben.
Schau mal hier:
http://www.pilight.org/faq/#general_two
http://forum.pilight.org/Thread-Solved-No-ssdp-connection-found
Risiko.
Guten Abend Risiko!
Erstmals hrezlichen Dank für deine Bereitschaft Unterstützung zu geben!
Den Switch habe ich wie folgt definiert:
Zitatdefine _CLARUS pilight_ctrl localhost:5000
attr _CLARUS brands Clarus
attr _CLARUS verbose 5
define Hutlampe pilight_switch clarus_switch "A2" 44
attr Hutlampe devStateIcon on:li_wht_on off:li_wht_off
attr Hutlampe group Licht_Wohnzimmer
attr Hutlampe icon light_floor_lamp
attr Hutlampe room Wohnzimmer
attr Hutlampe verbose 5
Der Log von 1x ein und wieder aus Schalten (über fhem, nicht büber die Fernbedienung) ist:
Zitat2015.03.15 18:55:33 4: _CLARUS(Parse): RCV -> {"message":{"id":"F0","unit":0,"state":"off"},"origin":"receiver","protocol":"clarus_switch","uuid":"0000-b8-27-eb-f724b0","repeats":1}
2015.03.15 18:55:42 4: Hutlampe(Set): on
2015.03.15 18:55:42 4: _CLARUS(Write): RCV (pilight_switch) -> Hutlampe,on
2015.03.15 18:55:42 4: _CLARUS(Write): {"action":"send","code":{"protocol":["clarus_switch"],"id":"A2","unit":44,"on":1}}
2015.03.15 18:55:42 5: _CLARUS(SendNonBlocking): [1] {"action":"send","code":{"protocol":["clarus_switch"],"id":"A2","unit":44,"on":1}}
2015.03.15 18:55:42 5: _CLARUS(Send): {"action":"send","code":{"protocol":["clarus_switch"],"id":"A2","unit":44,"on":1}}
2015.03.15 18:55:42 5: _CLARUS(Send): RCV -> {"status":"success"}
2015.03.15 18:55:42 4: _CLARUS(SendDone): message successfully send
2015.03.15 18:55:43 4: _CLARUS(Parse): RCV -> {"origin":"sender","protocol":"clarus_switch","message":{"id":"A2","unit":44,"state":"on"},"repeat":1,"uuid":"0000-b8-27-eb-f724b0"}
2015.03.15 18:55:43 5: _CLARUS dispatch SWITCH,clarus_switch,A2,44,on
2015.03.15 18:55:43 4: pilight_switch_Parse: RCV -> SWITCH,clarus_switch,A2,44,on
2015.03.15 18:55:43 3: _CLARUS: Unknown code SWITCH,clarus_switch,A2,44,on, help me!
2015.03.15 18:55:49 4: Hutlampe(Set): off
2015.03.15 18:55:49 4: _CLARUS(Write): RCV (pilight_switch) -> Hutlampe,off
2015.03.15 18:55:49 4: _CLARUS(Write): {"action":"send","code":{"protocol":["clarus_switch"],"id":"A2","unit":44,"off":1}}
2015.03.15 18:55:49 5: _CLARUS(SendNonBlocking): [1] {"action":"send","code":{"protocol":["clarus_switch"],"id":"A2","unit":44,"off":1}}
2015.03.15 18:55:49 5: _CLARUS(Send): {"action":"send","code":{"protocol":["clarus_switch"],"id":"A2","unit":44,"off":1}}
2015.03.15 18:55:49 5: _CLARUS(Send): RCV -> {"status":"success"}
2015.03.15 18:55:49 4: _CLARUS(SendDone): message successfully send
2015.03.15 18:55:49 4: _CLARUS(Parse): RCV -> {"origin":"sender","protocol":"clarus_switch","message":{"id":"A2","unit":44,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-f724b0"}
2015.03.15 18:55:49 5: _CLARUS dispatch SWITCH,clarus_switch,A2,44,off
2015.03.15 18:55:49 4: pilight_switch_Parse: RCV -> SWITCH,clarus_switch,A2,44,off
2015.03.15 18:55:49 3: _CLARUS: Unknown code SWITCH,clarus_switch,A2,44,off, help me!
Zwischendrin wurden noch von Nachbarn diverse Schaltbefehle empfangen
Wie gesagt, das Schalten selbst funktioniert.
Und wenn ich via Fernbedienung schalte, erhalte ich folgendes Log
Zitat2015.03.15 19:13:22 4: _CLARUS(Parse): RCV -> {"message":{"id":"A2","unit":44,"state":"on"},"origin":"receiver","protocol":"clarus_switch","uuid":"0000-b8-27-eb-f724b0","repeats":6}
2015.03.15 19:13:22 5: _CLARUS dispatch SWITCH,clarus_switch,A2,44,on
2015.03.15 19:13:22 4: pilight_switch_Parse: RCV -> SWITCH,clarus_switch,A2,44,on
2015.03.15 19:13:22 3: _CLARUS: Unknown code SWITCH,clarus_switch,A2,44,on, help me!
2015.03.15 19:13:26 4: _CLARUS(Parse): RCV -> {"message":{"id":"A2","unit":44,"state":"off"},"origin":"receiver","protocol":"clarus_switch","uuid":"0000-b8-27-eb-f724b0","repeats":1}
2015.03.15 19:13:26 5: _CLARUS dispatch SWITCH,clarus_switch,A2,44,off
2015.03.15 19:13:26 4: pilight_switch_Parse: RCV -> SWITCH,clarus_switch,A2,44,off
2015.03.15 19:13:26 3: _CLARUS: Unknown code SWITCH,clarus_switch,A2,44,off, help me!
Nocmals Danke für deine Unterstützung!
Chipmunk
Hallo chipmunk.
Auf die Schnelle konnte ich nicht viel erkennen.
Scheinbar ist beim Vergleich der ID's noch ein Fehler. Schaue ich mir morgen näher an.
Meiner Meinung nach sollte das gehen:
define Hutlampe pilight_switch clarus_switch A2 44
Ohne '"'.
Das Attribut brands wird nicht benötigt, macht aber auch nichts falsch.
Risiko
Hi Risiko!
Kann es sein, dass das Problem darin besteht, dass Pilight_switch als id eine Zahl erwartet (darauf deutet dein Kommentar ohne "" hin), aber der pilight daemon eine string liefert (daher das "")?
Pilight selbst erwartet beim senden (also ohne fhem) ebenfalls einen String.
Nachtrag: ohne die Anführungszeichen um A2 (also ID A2 statt "A2") ergibt der Versuch mit pilight_switch zu schalten einen Error
Nachtrag 2: genau das dürfte das Problem sein: zum Schalten sind die Anführungszeichen bei der ID nötig, für den Status dürfen die Anführungszeichen nicht vorhanden sein. Verifiziert, indem ich einen zweiten Switch (test) ohne die Anführungszeichen bei der ID definiert habe. Wenn ich jetzt den Hutswitch schalte (den mit den ""), ändert sich bei test der Status, nicht jedoch bei Hutswitch.
Mit test kann ich jedoch nicht schalten. Auch bei Verwendung der Fernbedienung ändert sich nur bei test der Status.
Chipmunk
Hallo chipmunk,
ich habe pilight_ctrl im Eingangsposting aktualisiert. Nun sollte es gehen.
Die ID trotzdem ohne '"' definieren.
Risiko.
Hi Risiko!
Vielen Dank jetzt funktioniert es!
Ein Device, mit dem man schalten kann und den Status angezeigt bekommt - Super!
Chipmunk
Hallo Risiko,
vielen Dank für dein Modul. Dass man mit diesem auch Befehle empfangen kann finde ich absolut genial. Viel günstiger kommt man vermutlich nicht an eine Fernbedienung für FHEM ;)
Aber zum regulären Schalten: Ich nutze als Funksteckdosen die Brennenstuhl Comfort RCS 1000N welche entgegen der Pilight Doku nicht mit einem Elro Protokoll sondern mit dem Cleverwatts Protokoll senden. Ich tippe mal auf eine neue Hardware Revision.
Die Befehle Befehle für Pilight sehen so aus:
An:
pilight-send -p cleverwatts -i <id> -a 1 -f
Aus:pilight-send -p cleverwatts -i <id> -u 1 -t
Die Werte für -a und -u sind immer 1
Meinst du, du könntest dieses Protokoll in das Modul integrieren?
Schon mal vielen Dank :)
Hallo tealc,
ich habe das Protokoll cleverwatts hinzugefügt. Es sollte gehen.
Risiko.
Hallo Risiko,
könntest du dich schon dem Modul für Wetterstationen annehmen?
Bei mir funkt ein Nachbar über alecto wsd 17 und ws1700.
Wäre natürlich cool, wenn ich die Daten loggen und darstellen könnte.
Grüße Frank
Zitat von: Risiko am 19 März 2015, 21:22:17
Hallo tealc,
ich habe das Protokoll cleverwatts hinzugefügt. Es sollte gehen.
Risiko.
Hallo Risiko,
ich wollte dir gerade das Pilight-Receive Log posten, da sehe ich, dass du schon fleißig warst. Danke :)
Leider funktioniert nur das ausschalten.
Beim Einschalten muss nicht der Unit-Code (-u) mitgegeben sondern der All (-a):
pilight-send -p cleverwatts -i 786154 -a 1 -t
{
"origin": "sender",
"protocol": "cleverwatts",
"message": {
"id": 786154,
"all": 1,
"state": "on"
},
"repeat": 1,
"uuid": "0602-53-78-48-554848"
}Interessanter Weise funktioniert das anschalten mit -f anstatt -t auch:
pilight-send -p cleverwatts -i 786154 -a 1 -f
{
"origin": "sender",
"protocol": "cleverwatts",
"message": {
"id": 786154,
"all": 1,
"state": "off"
},
"repeat": 1,
"uuid": "0602-53-78-48-554848"
}
Was ebenfalls funktioniert ist, -u zusätzlich zum -a mitzusenden:
pilight-send -p cleverwatts -i 786154 -a 1 -f -u 0
Das -u scheint auf Empfängerseite zu dem Zeitpunkt aber komplett ignoriert zu werden sofern dessen Werte zwischen 0 und7 liegen.Vermutlich ist irgendwo in Pilight da genau ein Byte für vorgesehen.
{
"origin": "sender",
"protocol": "cleverwatts",
"message": {
"id": 786154,
"all": 1,
"state": "on"
},
"repeat": 1,
"uuid": "0602-53-78-48-554848"
}
Fassen wir zusammen: Beim Einschalten unit durch all ersetzen oder ein -a 1 anhängen und es müsste funktionieren :)
Wäre cool, wenn du da noch mal reinschauen könntest :)
Edit:
Der -a Parameter in der Konsole scheint binär zu sein. anstatt "-a 1" kann man auch nur "-a" benutzen. Aber das ist für den Websocket-Aufruf wahrscheinlich uninteressant.
@shiiva
Das liegt noch auf meiner ToDo-Liste. Habe noch keine passenden Sensoren. Diese sind aber unterwegs und wenn diese funktionieren, dann baue ich auch ein Modul.
Bitte etwas Geduld.
Risiko.
@tealc,
ist schon etwas seltsam. Mit all würde man doch aber alle\mehrere Schalter (Gruppe) schalten, was so aber nicht gewollt ist.
Ich habe in pilight zum Test mal einen cleverwatts Switch konfiguriert und kann diesen in FHEM über id und unit an und aus schalten.
{
"origin": "sender",
"protocol": "cleverwatts",
"message": {
"id": 1,
"unit": 0,
"state": "on"
},
"repeat": 1,
"uuid": "0000-00-00-5b-786cb0"
}
Es geht auch pilight-send -p cleverwatts -i 1 -u 0 -t
Aus meiner Sicht alles i.O.
Was passiert denn bei dir, wenn du mit der unit statt all einschalten willst?
Hast du mehr als einen Schalter mit ID 786154 aber unterschiedlichen unit's?
Die "all" - Logik ist im gesamten Modul (noch) nicht vorgesehen.
Es gibt ja auch andere Protokolle, die all unterstützen. Wie man das im Modul abbilden könnte, habe ich mir noch keine Gedanken gemacht.
Jetzt einfach ein "all" zu senden, lehne ich aber erstmal ab.
Aus meiner Sicht wäre erstmal zu klären, warum es mit unit nicht geht\gehen soll. Evtl. mal im pilight-forum suchen\fragen.
Risiko.
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 von der Fernbedienung läuft super. Wenn ich allerdings über FHEM die Steckdose 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
Hallo raspberry,
Es ist wichtig, dass von der Reihenfolge der defines erst pilight_ctrl definiert wird.
Die Verbindung zwischen den zweistufigen Modulen erfolgt in fhem.pl
Das Zuweisen von $hash->{IODev} erfolgt in AssignIoPort. Evtl. solltest du auch mal fhem updaten.
Ich denke aber, dass es an der Reihenfolge liegt.
Risiko.
Zitat von: Risiko am 22 März 2015, 15:06:56
Was passiert denn bei dir, wenn du mit der unit statt all einschalten willst?
Hast du mehr als einen Schalter mit ID 786154 aber unterschiedlichen unit's?
Es passiert gar nichts. Jeder Schalter hat eine unterschiedliche ID. Die unit ist immer 1
Zitat von: Risiko am 22 März 2015, 15:06:56
Aus meiner Sicht wäre erstmal zu klären, warum es mit unit nicht geht\gehen soll. Evtl. mal im pilight-forum suchen\fragen.
Risiko.
Aus meiner Sicht ist das keine Problem von Pilight. Die Fernbedienung sendet ja auch mit dem All-Flag. Eine All-Taste gibt es auf ihr gar nicht.
Ich denke, das ist einfach eine Eigenart dieser Sender / Steckdosen, dass sie ein abgewandeltes Cleverwatts Protokoll nutzen, dass sich nicht mit dem Protokoll der Funksteckdosen des Herstellers Cleverwatts deckt.
Hallo tealc,
ich habe für das cleverwatts-Protokoll all für die unit eingebaut. Siehe 1. Beitrag.
Wenn man den Switch mit unit all definiert wird "all":1 gesendet und beim Empfang wird dann all wieder auf unit abgebildet.
Somit solltest es funktionieren.
Wenn nun aber mehrere Schalter\Dosen mit gleicher id und unterschiedlichen units existieren, werden bei einem Empfang von all aktuell nicht alle schalten, sondern nur der Schalter mit unit all. Das gibt es nach deiner Aussage "Die unit ist immer 1" ja nicht.
Risiko.
Hallo.
Nun gibt es auch eine Repräsentation eines Temperatur- und Luftfeuchtigkeitssensors (siehe 1. Beitrag)
Risiko.
Zitat von: Risiko am 26 März 2015, 20:30:05
Hallo tealc,
ich habe für das cleverwatts-Protokoll all für die unit eingebaut. Siehe 1. Beitrag.
Wenn man den Switch mit unit all definiert wird "all":1 gesendet und beim Empfang wird dann all wieder auf unit abgebildet.
Somit solltest es funktionieren.
Wenn nun aber mehrere Schalter\Dosen mit gleicher id und unterschiedlichen units existieren, werden bei einem Empfang von all aktuell nicht alle schalten, sondern nur der Schalter mit unit all. Das gibt es nach deiner Aussage "Die unit ist immer 1" ja nicht.
Risiko.
Hallo Risiko,
mit der aktuellen Funktion funktioniert nun das An- aber nicht mehr das Ausschalten. Beim Ausschalten muss ja die Unit 1 gesendet werden und kein All:
Zitat von: tealc am 19 März 2015, 20:45:09
Die Befehle Befehle für Pilight sehen so aus:
An:
pilight-send -p cleverwatts -i <id> -a 1 -f
Aus:pilight-send -p cleverwatts -i <id> -u 1 -t
Hallo tealc.
Für mich ist das aber alles sehr sehr unlogisch und sieht eher nach einem Bug in pilight aus. Wieso 'all' nur in eine Richtung funktionieren soll.
Welche Version verwendest du?
Ich habe leider die Hardware nicht aber mit einem konfiguriertem Cleverwatts-Schalter funktioniert alles wie soll.
Könntest du dies bitte mal testen - also Schalter in config.json (Version 6.0, siehe Anhang) einbauen. Dann kannst das auch mit der pilight-WebGui testen.
Das beschriebene Verhalten einzubauen, wäre schon eine ganz schöne Vergewaltigung. Daher bitte um Verständnis und um die Rückfragen.
Risiko.
Ich benutze pilight v6.0 / filter firmware v50319.
Der Einbau in die Webgui ist wie erwartet analog zu der Konsole. Ausschalten geht (da wird ja kein all benötigt), Einschalten nicht.
Prinzipiell hast du schon recht, dass die Geschichte irgendwie keinen Sinn macht. Vermutlich ist dieses Protokoll nicht sauber in Pilight implementiert.
Da jetzt auf Pilight-Ebene zu debuggen ist wahrscheinlich sehr aufwendig. Ich habe mir jetzt Quick&Dirthy einen kleinen Workaround eingebaut.
switch($cType){
case m/switch/ {
$code = "{\"protocol\":[\"$proto\"],";
switch ($proto) {
case m/elro/ {$code .= "\"systemcode\":$id,\"unitcode\":$unit,";}
case m/silvercrest/ {$code .= "\"systemcode\":$id,\"unitcode\":$unit,";}
case m/mumbi/ {$code .= "\"systemcode\":$id,\"unitcode\":$unit,";}
case m/brennenstuhl/ {$code .= "\"systemcode\":$id,\"unitcode\":$unit,";}
case m/pollin/ {$code .= "\"systemcode\":$id,\"unitcode\":$unit,";}
case m/impuls/ {$code .= "\"systemcode\":$id,\"programcode\":$unit,";}
case m/rsl366/ {$code .= "\"systemcode\":$id,\"programcode\":$unit,";}
case m/cleverwatts/ { $code .= "\"id\":$id,\"unit\":$unit,";
if ($state eq "on") {
$code .= "\"all\":1,";
}
}
else {$code .= "\"id\":$id,\"unit\":$unit,";}
}
$code .= "\"$state\":1}";
}
Damit komme ich erst mal weiter. Ich kann verstehen, dass du so eine "Bastelei" nicht in dein Plugin aufnehmen willst.
Trotzdem vielen, vielen Dank für deine Bemühungen :)
Moin,
nachdem pimatic die 6.0er Version von pilight nicht mehr unterstützt, bin ich freudig auf dein FHEM Modul gestoßen. Somit ist die Entscheidung doch auf FHEM zu setzen für mich weitestgehend gefallen.
Kannst du in dein Modul auch eine Unterstützung für das Auslesen von DHT22 Sensoren einbauen? Dies ist ja bislang unter FHEM recht umständlich (http://forum.fhem.de/index.php/topic,25413.msg201619.html#msg201619 (http://forum.fhem.de/index.php/topic,25413.msg201619.html#msg201619)), unter pilight jedoch sehr einfach. Somit wäre es m.E. recht elegant das Auslesen durch pilight erledigen zu lassen (wenn dieses sowieso läuft) und die Daten über dein Modul in FHEM zu importieren (wenn ich das richtig sehe, müsste das genauso wie die Funktemperatursensoren funktionieren, d.h. nur eine Ergänzung case m/dht/ {$protoID = 4;} bei den Protokolldefinitionen)
Vielen Dank für dein Modul - ich werde es in den nächsten Tagen auf jeden Fall testen!
Hallo zusammen,
erstmal vielen Dank für das Modul, nur leider möchte es bei mir nicht so wirklich funktionieren.
#Pilight
define pilight pilight_ctrl localhost:5000
attr pilight brands elro
attr pilight room pilight
define WZ_Lampe pilight_switch elro_800_switch 31 8
attr WZ_Lampe room pilight
Wenn ich den Befehl im Shell eingebe funktioniert das schalten problemlos.
Als status steht beim pilight_Ctrl modul opened!?
Hoffe ihr könnt mir helfen
Danke
Yves
Edit: Habe eben noch mal den Port überprüft. Anscheinend war bei mir der Port 5000 schon belegt, habe daher die Config auf 6000 geändert und schon funktioniert es... Das Modul schaltet schnell und tunnelt pilight sehr gut
Hallo gustav,
nicht ganz. Aber ich habe es eingebaut. Kann es selbst aber nicht testen.
Risiko
Hallo lulli,
opened ist erstmal ok. Dein brands Attribut aber nicht.
Was sagt den pilight-receive, wenn du den Befehl in der Shell (nehme an Linux-Shell) ein gibst?
elro_800 wird in pilight auch mit brennenstuhl umgesetzt. Evtl. musst du dafür das Attribut brands richtig angeben z.B. elro_800:brennenstuhl oder brennenstuhl:elro_800.
Kannst du bitte verbose von pilight_ctrl mal auf 5 stellen und schauen was im Log ankommt.
Weiterhin wäre ein list pilight (so hast du es ja genannt) in der FHEM-Eingabezeile interessant.
Risiko
Hallo Risiko,
hatte den falschen Port angegeben. 5000 war anscheinend schon belegt, habe die config daher auf 600 geändert und schon klappt es.
Internals:
API 6.0
CHECK 1
DEF localhost:6000
DeviceName localhost:6000
FD 76
NAME pilight
NR 436
PARTIAL
STATE opened
TYPE pilight_ctrl
Readings:
2015-03-30 20:22:12 rcv_raw {"message":{"id":6,"unit":5,"state":"off"},"origin":"receiver","protocol":"conrad_rsl_switch","uuid":"0000-00-00-51-94a9c1","repeats":1}
2015-03-30 20:03:16 state opened
Helper:
CON connected
LAST_RCV_PROTOCOL conrad_rsl_switch
LAST_RCV_RAW {"message":{"id":6,"unit":5,"state":"off"},"origin":"receiver","protocol":"conrad_rsl_switch","uuid":"0000-00-00-51-94a9c1","repeats":1}
LAST_SEND_RAW {"action":"send","code":{"protocol":["elro_800_switch"],"systemcode":31,"unitcode":8,"on":1}}
SEND_CNT 1
Running_pid:
abortFn pilight_ctrl_SendAbort
finishFn pilight_ctrl_SendDone
fn pilight_ctrl_Send
pid 4835
Abortarg:
SEND_DATA:
{"action":"send","code":{"protocol":["pollin"],"systemcode":31,"unitcode":8,"on":1}}
Attributes:
brands elro
room pilight
schalten klappt leider nicht. die fernbedienungen werden allerdings alle erkannt.
Gruß
Yves
Ich sehe da drei unterschiedliche Protokolle conrad_rsl_switch, pollin und elro_800_switch.
Sicherlich nicht richtig, oder hast du noch andere Schalter?
Also ohne Log's bzw. Ausgaben von pilight-receive kann ich auch nicht mehr sagen.
Was meinst du mit Fernbedienungen werde erkannt aber Schalten geht aber nicht? Versteh ich nicht. Welche Richtung?
Risiko
Hi Risiko,
ich habe hier jede Menge von den Dosen rumfliegen. ;D
{
"message": {
"systemcode": 31,
"unitcode": 8,
"state": "closed"
},
"origin": "receiver",
"protocol": "elro_800_contact",
"uuid": "0000-00-00-51-94a9c1",
"repeats": 1
}
{
"message": {
"systemcode": 31,
"unitcode": 8,
"state": "off"
},
"origin": "receiver",
"protocol": "elro_800_switch",
"uuid": "0000-00-00-51-94a9c1",
"repeats": 1
}
Das zeigt mir pilight-receive an und manuell übers shell klappt bei mir auch das schlaten mit dem elro_800_switch protokoll..
2015.03.30 19:47:11 3: pilight(Write): Blocking Call running - will try it later
2015.03.30 19:47:11 3: pilight(Write): Blocking Call running - will try it later
2015.03.30 19:47:12 3: pilight(Write): Blocking Call running - will try it later
2015.03.30 19:47:12 3: pilight(Parse): unknown protocol -> ev1527
2015.03.30 19:47:12 3: pilight: Unknown code SWITCH,elro_400,0,29,off, help me!
2015.03.30 19:47:12 3: pilight: Unknown code SWITCH,pollin,31,8,off, help me!
2015.03.30 19:47:12 3: pilight: Unknown code SWITCH,elro_800_contact,31,8,closed, help me!
2015.03.30 19:47:12 3: pilight(Parse): unknown protocol -> ev1527
2015.03.30 19:47:12 3: pilight: Unknown code SWITCH,pollin,31,8,off, help me!
2015.03.30 19:47:12 3: pilight: Unknown code SWITCH,elro_800_contact,31,8,closed, help me!
2015.03.30 19:47:12 3: pilight(Parse): unknown protocol -> ev1527
2015.03.30 19:47:12 3: pilight: Unknown code SWITCH,pollin,31,0,on, help me!
2015.03.30 19:47:12 3: pilight: Unknown code SWITCH,elro_800_contact,31,0,opened, help me!
2015.03.30 19:47:12 3: pilight: Unknown code SWITCH,elro_800_switch,31,0,on, help me!
2015.03.30 19:47:12 3: pilight(Write): Blocking Call running - will try it later
2015.03.30 19:47:12 3: pilight(Parse): unknown protocol -> ev1527
2015.03.30 19:47:12 3: pilight: Unknown code SWITCH,pollin,31,0,on, help me!
2015.03.30 19:47:12 3: pilight: Unknown code SWITCH,elro_800_contact,31,0,opened, help me!
2015.03.30 19:47:12 3: pilight: Unknown code SWITCH,elro_800_switch,31,0,on, help me!
2015.03.30 19:47:13 3: pilight(Write): Blocking Call running - will try it later
2015.03.30 19:47:13 3: pilight(Write): Blocking Call running - will try it later
hier ein kurzer auszug aus meiner log datei. die ist inzwischen 65mb gross und daher sehr unübersichtlich.
danke für die hilfe
gruß
yves
Hi lulli,
Da scheint noch ein Senden von FHEM zu hängen.
pilight(Write): Blocking Call running - will try it later
bzw.
Running_pid: ...
Ich empfehle FHEM mal neu zu starten und dann langsam mit einem Protokoll und Schalter anzufangen.
Dann eins nach dem Anderen.
Auf jeden Fall solltest du das Attribut brands löschen. Das wird hier nicht benötigt.
Wenn ich noch etwas Zeit finde, versuch ich mal einen elro_800_switch nachzustellen.
Risiko.
Hallo Risiko,
habe die Brands gelöscht und mein ganzen Pi neugestartet. Außerdem habe ich powerpi gelöscht, welches ist parallel mal zum testen auf dem PI installiert hatte.
Jetzt funktioniert es .
Danke für die Hilfe. Dein Modul ist echt Top.
Hallo zusammen,
ich bin etwas erstaunt, das das define bei mir ein wenig anders aussieht :)
Ich bin gerade dabei meine Funksteckdosen auf FHEM "umzuziehen"
Zum ansprechen dieser benutze ich einen 433 MHZ Sender aus der bucht + pilight.
Soweit nichts großes. Meine Impuls Dosen tun bereits ohne Probleme und sind sehr stabil was die Schaltungen angeht.
Ich habe jedoch noch eine Handvoll Elros rumfliegen, die mich gerade ein wenig ärgnern.
Dazu meine analyse:
define:
define Stehlampe pilight elro_800_switch
attr Stehlampe eventMap on:on off:off
attr Stehlampe room Stube
attr Stehlampe systemcode 15
attr Stehlampe unitcode 1
Geht in diesem Aufbau mit Protokoll Impuls wunderbar.
Im Log die Ursache:
2015.04.01 22:58:11 3: pilight data: { "action": "send", "code": {"protocol":[ "impuls" ],"systemcode":1, "programcode":2,"on":1}}
2015.04.01 22:58:13 3: pilight command: off
2015.04.01 22:58:13 3: pilight data: { "action": "send", "code": {"protocol":[ "impuls" ],"systemcode":1, "programcode":2,"off":1}}
2015.04.01 22:58:20 3: pilight command: on
2015.04.01 22:58:20 3: pilight data: { "action": "send", "code": {"protocol":[ "elro_800_switch" ],}}
2015.04.01 22:58:22 3: pilight command: off
2015.04.01 22:58:22 3: pilight data: { "action": "send", "code": {"protocol":[ "elro_800_switch" ],}}
Scheinbar werden Systemcode und Unitcode nicht mit übergeben.
Test auf der Console per pilight-send war erfolgreich.
Ich habe das Define auch schon anders aufgebaut:
define Stehlampe pilight elro_800_switch 15 1
Leider ebenfalls ohne Erfolg.
Wer kann mich erleuchten? :)
Viele Grüße
Marcel
Hallo Marcel,
wie du im 1st Post sehen kannst handelt es sich hier um die Module
pilight_ctrl: - Basismodul für die Kommunikation
define <name> pilight_ctrl <host:port> [api]
host - IP wo der pilight-daemon läuft
port - Port des pilight-daemon
api - pilight version optional, 5.0 oder 6.0 - default 6.0
pilight_switch: - Repräsentation eines Schalters
define <name> pilight_switch <protocol> <id> <unit>
protocol - Protokoll z.B. kaku_switch
id - ID oder Systemcode je nach Protokoll
unit - unit, unitcode oder programcode je nach Protokoll
wenn Du diese Module Fhem hinzufügst und Dein Pilight_ctrl definierst sollte der Befehl
define Stehlampe pilight_switch elro_800_switch 15 1
funktionieren.
gruß
Yves
Hallo Marcel,
du verwendest nicht das "richtige" Modul(e). Siehe 1. Beitrag.
Risiko.
@Yves
Danke.
Nabend,
ich bin auch ein Noob und versuche meinen FHEM in die Reihe zu bekommen.
Pilight Module sind eingbaut und FHEM aktuell.
Ich habe einige Steckdosen die ich über die Pilight Webgui schalten kann, über die Konsole ghet es aber komischerweise nicht.
Meine Konfig sieht wie folgt aus:
in Pilight "WZStehlampe": {
"protocol": [ "elro_800_switch" ],
"id": [{
"systemcode": 20,
"unitcode": 1
}],
"state": "on"
},
das funktioniert über die Webgui
in FHEM:
## Pilight ##
define pilight pilight_ctrl localhost:5000
define WZ_Stehlampe pilight_switch elro_800_switch 20 1
attr WZ_Stehlampe group WZ
attr WZ_Stehlampe room EG_Licht,Wohnzimmer
Im FHEM LOG kommt:
2015.04.08 19:41:13 3: Opening pilight device localhost:5000
2015.04.08 19:41:13 3: pilight device opened
2015.04.08 19:41:13 1: Including ./log/fhem.save
2015.04.08 19:43:50 1: Timeout for pilight_ctrl_Send reached, terminated process 8723
2015.04.08 19:43:50 2: pilight(SendAbort): ERROR. sending aborted
2015.04.08 19:43:52 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:43:52 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:43:53 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:44:04 1: Timeout for pilight_ctrl_Send reached, terminated process 8724
2015.04.08 19:44:04 2: pilight(SendAbort): ERROR. sending aborted
2015.04.08 19:44:04 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:44:04 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:44:04 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:44:04 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:44:04 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:44:04 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:44:05 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:44:05 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:44:06 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:44:06 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:44:07 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:44:07 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:44:08 3: pilight(Write): Blocking Call running - will try it later
2015.04.08 19:44:08 1: Timeout for pilight_ctrl_Send reached, terminated process 8725
2015.04.08 19:44:08 2: pilight(SendAbort): ERROR. sending aborted
2015.04.08 19:44:12 1: Timeout for pilight_ctrl_Send reached, terminated process 8726
2015.04.08 19:44:12 2: pilight(SendAbort): ERROR. sending aborted
Kann mir jemand sagen was ich falsch mache?
Danke
Hallo,
ich bin nun schon soweit dass ich auch über die Konsole schalten kann (Brennenstuhl, elro_800_switch) aber über fhem gehts immer noch nicht. Hab jetzt auch nochmal den Raspi neu aufgesetzt und Pilight, JSON, FHEM installiert. Hab auch noch nix weiter eingebunden als meine Steckdose. pilight_ctrl und pilight_switch sind eingerichtet aber es geht nichts raus. Ab und an kommt es auch vor dass fhem sich verabschiedet und neu gestartet werden muss. Die Module ctrl und switch habe ich in den FHEM Ordner kopiert und den Raspi neu gestartet.
Ich bin mit meinem Latein am Ende und hoffe nun auf euch.
Btw.: was hat es eigentlich mit dem 98_pilight.pm Modul auf sich? Ist das noch von einem anderen Entwickler?
Th.
Edit:
hier mal noch Meldungen aus dem Log:
2015.04.09 13:00:48 1: Timeout for pilight_ctrl_Send reached, terminated process 2266
2015.04.09 13:00:48 2: Pilight(SendAbort): ERROR. sending aborted
Einen Fehler: malformed json strin ... im modul 10_pilight_ctrl.pm Zeile 511 habe ich auch zwischendurch mal bekommen.
Kann mir jemand die Unterschiede/Vorteile/Nachteile gegenüber dem Modul erklären?
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/98_pilight.pm
http://fhem.de/commandref.html#pilight
Beim 10_pilight_ctrl.pm Modul werden die Device-Einstellungen direkt von der pilight Konfiguration gezogen und mit dem 98_pilight.pm Modul legt man die Devices physisch erst in FHEM an?
So wie ich das verstehe hat das 98_pilight mit den hier besprochenen nichts zu tun (korrigiert mich wenn ich falsch liege).
Bei mir laufen allerdings weder das Eine noch die Anderen :(
>:(
Hallo update71,
kann es sein, dass der pilight-daemon nicht auf Port 5000 läuft! Das muss man explizit in der Konfigurationsdatei (config.json) angeben.
Ich habe in diesem Zusammenhang noch was gefixt. Siehe 1. Beitrag.
Wenn keine Verbindung zu pilight aufgebaut werden kann, bekommt man jetzt eine Fehlermeldung.
Risiko.
Hi, der läuft auf 5000 ... ich frickel da jetzt schon seit Stunden dran rum und hab so ziemlich alles was im Netz steht durch :(
Das im FHEM integrierte Modul tuts auch nicht.
Wenn du irgendwas an LOGs etc. brauchst dann gib Bescheid.
Th.
Hallo Hauswart,
pilight.pm ist von A. Fey. Mit diesem Modul kann man nur Senden und es unterstützt nur pilight Version < 5.0
Meine Kontaktaufnahme zu einer gemeinsamen Weiterentwicklung ist damals gescheitert, so dass ich mich für diesen Weg (neue Module) entschieden habe.
Risiko.
@update71
1. Führ mal bitte list pilight in der FHEM-Befehlszeile aus
2. Stelle verbose mal auf 5 - dann kommen mehr Log's
Was für eine pilight Version verwendest du?
Risiko
Hi, hier mal "list Pilight"
Internals:
API 6.0
CFGFN
DEF localhost:5000
DeviceName localhost:5000
NAME Pilight
NR 28
PARTIAL
RETRY_INTERVAL 60
STATE disconnected
TYPE pilight_ctrl
Readings:
2015-04-09 20:34:26 state disconnected
Helper:
CHECK 0
CON diconnected
NEXT_TRY 1428604526
Attributes:
room test
Und was aus dem LOG:
2015.04.09 20:28:38 3: Opening Pilight device localhost:5000
2015.04.09 20:28:39 3: Pilight device opened
2015.04.09 20:28:51 1: localhost:5000 disconnected, waiting to reappear (Pilight)
2015.04.09 20:29:54 3: Opening Pilight device localhost:5000
2015.04.09 20:29:54 3: Pilight device opened
2015.04.09 20:30:06 1: localhost:5000 disconnected, waiting to reappear (Pilight)
2015.04.09 20:30:34 3: Opening Pilight device localhost:5000
2015.04.09 20:30:34 3: Pilight device opened
2015.04.09 20:30:46 1: localhost:5000 disconnected, waiting to reappear (Pilight)
2015.04.09 20:31:50 3: Opening Pilight device localhost:5000
2015.04.09 20:31:50 3: Pilight device opened
2015.04.09 20:32:02 1: localhost:5000 disconnected, waiting to reappear (Pilight)
2015.04.09 20:32:03 2: Pilight(Write): ERROR: no connection to pilight-daemon localhost:5000
2015.04.09 20:32:07 2: Pilight(Write): ERROR: no connection to pilight-daemon localhost:5000
2015.04.09 20:32:09 2: Pilight(Write): ERROR: no connection to pilight-daemon localhost:5000
2015.04.09 20:33:02 3: Opening Pilight device localhost:5000
2015.04.09 20:33:02 3: Pilight device opened
2015.04.09 20:33:14 1: localhost:5000 disconnected, waiting to reappear (Pilight)
2015.04.09 20:34:14 3: Opening Pilight device localhost:5000
2015.04.09 20:34:14 3: Pilight device opened
2015.04.09 20:34:26 1: localhost:5000 disconnected, waiting to reappear (Pilight)
2015.04.09 20:35:29 3: Opening Pilight device localhost:5000
2015.04.09 20:35:29 3: Pilight device opened
2015.04.09 20:35:41 1: localhost:5000 disconnected, waiting to reappear (Pilight)
2015.04.09 20:36:21 2: Pilight(Write): ERROR: no connection to pilight-daemon localhost:5000
2015.04.09 20:36:23 2: Pilight(Write): ERROR: no connection to pilight-daemon localhost:5000
Sorry, ist echt viel:
2015.04.09 20:36:41 3: Opening Pilight device localhost:5000
2015.04.09 20:36:41 3: Pilight device opened
2015.04.09 20:36:41 5: Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:36:41 4: Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:36:41 5: SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2015.04.09 20:36:42 5: Pilight(Check): identify
2015.04.09 20:36:43 5: Pilight(Check): identify
2015.04.09 20:36:44 5: Pilight(Check): identify
2015.04.09 20:36:44 5: Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:36:44 4: Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:36:44 5: SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2015.04.09 20:36:45 5: Pilight(Check): identify
2015.04.09 20:36:46 5: Pilight(Check): identify
2015.04.09 20:36:47 5: Pilight(Check): identify
2015.04.09 20:36:47 5: Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:36:47 4: Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:36:47 5: SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2015.04.09 20:36:48 5: Pilight(Check): identify
2015.04.09 20:36:49 5: Pilight(Check): identify
2015.04.09 20:36:50 5: Pilight(Check): identify
2015.04.09 20:36:50 5: Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:36:50 4: Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:36:50 5: SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2015.04.09 20:36:51 5: Pilight(Check): identify
2015.04.09 20:36:52 5: Pilight(Check): identify
2015.04.09 20:36:53 5: Pilight(Check): identify
2015.04.09 20:36:53 4: Pilight(Check): Could not connect to pilight-daemon localhost:5000 - maybe wrong api version or port
2015.04.09 20:36:53 1: localhost:5000 disconnected, waiting to reappear (Pilight)
2015.04.09 20:37:54 3: Opening Pilight device localhost:5000
2015.04.09 20:37:54 3: Pilight device opened
2015.04.09 20:37:54 5: Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:37:54 4: Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:37:54 5: SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2015.04.09 20:37:55 5: Pilight(Check): identify
2015.04.09 20:37:56 5: Pilight(Check): identify
2015.04.09 20:37:57 5: Pilight(Check): identify
2015.04.09 20:37:57 5: Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:37:57 4: Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:37:57 5: SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2015.04.09 20:37:58 5: Pilight(Check): identify
2015.04.09 20:37:59 5: Pilight(Check): identify
2015.04.09 20:38:00 5: Pilight(Check): identify
2015.04.09 20:38:00 5: Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:38:00 4: Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:38:00 5: SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2015.04.09 20:38:01 5: Pilight(Check): identify
2015.04.09 20:38:02 5: Pilight(Check): identify
2015.04.09 20:38:03 5: Pilight(Check): identify
2015.04.09 20:38:03 5: Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:38:03 4: Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:38:03 5: SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2015.04.09 20:38:04 5: Pilight(Check): identify
2015.04.09 20:38:05 5: Pilight(Check): identify
2015.04.09 20:38:06 5: Pilight(Check): identify
2015.04.09 20:38:06 4: Pilight(Check): Could not connect to pilight-daemon localhost:5000 - maybe wrong api version or port
2015.04.09 20:38:06 1: localhost:5000 disconnected, waiting to reappear (Pilight)
2015.04.09 20:38:23 2: Pilight(Write): ERROR: no connection to pilight-daemon localhost:5000
2015.04.09 20:38:25 2: Pilight(Write): ERROR: no connection to pilight-daemon localhost:5000
2015.04.09 20:38:27 2: Pilight(Write): ERROR: no connection to pilight-daemon localhost:5000
2015.04.09 20:39:09 3: Opening Pilight device localhost:5000
2015.04.09 20:39:09 3: Pilight device opened
2015.04.09 20:39:09 5: Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:39:09 4: Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:39:09 5: SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2015.04.09 20:39:10 5: Pilight(Check): identify
2015.04.09 20:39:11 5: Pilight(Check): identify
2015.04.09 20:39:12 5: Pilight(Check): identify
2015.04.09 20:39:12 5: Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:39:12 4: Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:39:12 5: SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2015.04.09 20:39:13 5: Pilight(Check): identify
2015.04.09 20:39:14 5: Pilight(Check): identify
2015.04.09 20:39:15 5: Pilight(Check): identify
2015.04.09 20:39:15 5: Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:39:15 4: Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:39:15 5: SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2015.04.09 20:39:16 5: Pilight(Check): identify
2015.04.09 20:39:17 5: Pilight(Check): identify
2015.04.09 20:39:18 5: Pilight(Check): identify
2015.04.09 20:39:18 5: Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:39:18 4: Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2015.04.09 20:39:18 5: SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2015.04.09 20:39:19 5: Pilight(Check): identify
2015.04.09 20:39:20 5: Pilight(Check): identify
2015.04.09 20:39:21 5: Pilight(Check): identify
2015.04.09 20:39:21 4: Pilight(Check): Could not connect to pilight-daemon localhost:5000 - maybe wrong api version or port
2015.04.09 20:39:21 1: localhost:5000 disconnected, waiting to reappear (Pilight)
@update71
Es kann keine Verbindung zu pilight aufgebaut werden!!
Verwechselst du nicht webserver-port für die WebGui und den pilight Port für die Kommunikation!!??
settings": {
"port": 5000,
"webserver-port": 5001,
}
Risiko.
Danke, das war es. Mir war nicht bewusst dass das 2 verschiedene Ports sind. Hätte vermutlich gereicht den Webserverport auf 5001 zu lassen und in der pilight config 5000 anzugeben. Ich war immer der Meinung dass es nur einen Port gibt.
Danke, Danke, Danke :)
Wenn du mir jetzt noch verraten kannst wie ich dort ein Symbol für on/off reinbekomme (wenn das geht) dann geb ich n Bier aus :)
Th.
Nach Änderung auf elro_800_switch kamen die Statuslampen allein :)
@Risiko
mit dem Protokoll Parameter scheint etwas nicht zu stimmen. Ich habe bei mir intertechno und intertechno_old.
wenn ich nun ein neues Device anlege:
define SHUTTER pilight_switch interntechno_switch 47114711 1
dann bekomme
Unknown code SWITCH,arctech_switch,47114711,1,on, help me!
zurück.
Gehe ich dann hin und ändere das Protokoll in arctech_switch, schalte on und schalte off und ändere dann das Protokoll wieder zurück in intertechno_switch läuft es.
Leider funktioniert dieser workaround nicht bei interntechno_old Protokoll.
btw. Danke für die neue Umsetzung der Anbindung zum pilight. Sieht schon sehr gut aus.
Hallo pattex
das liegt an pilight und den unterschiedlichen Protokollnamen für ein Device. Dafür gibt es das Attribut brands.
Habe versucht das an einem Beispiel im 1. Post zu beschreiben.
Bei dir müsste also brands arctech:intertechno stehen (kaku ist auch Intertechno)
Schreibfehler? interntechno vs. intertechno
Risiko.
Bei mir ist auch der Log voll mit "Help me!" 8)
Geb ich bei Brands dann das Gleiche an wie beimSwitsch (elro_800_switch) oder nur "elro"?
Th.
@update71
Für elro_800 benötigt man kein brands. Hatten wir doch schon ;)
Scheinbar empfängst du mehr, (Stichwort Nachbar, Störungen,etc) wofür du aber kein Device definiert hast.
Dafür gibt es aktuell nur die Ignore-Liste (Attribut ignore).
Risiko
@Risiko
sorry, ich habe nun mit dem brands rumprobiert und komme leider mit meinem interechno_old nicht weiter.
brands habe ich auf arctech:intertechno gesetzt.
Das Device hat als protocol intertechno_old
Schalten kann ich, aber die Rückgabe des Status wird nicht richtig gemappt.
2015.04.12 12:27:11.777 4: pilight(Write): RCV (pilight_switch) -> BUERO_CHARGERS,on
2015.04.12 12:27:11.779 4: pilight(Write): {"action":"send","code":{"protocol":["intertechno_old"],"id":2,"unit":0,"on":1}}
2015.04.12 12:27:11.781 5: pilight(SendNonBlocking): [1] {"action":"send","code":{"protocol":["intertechno_old"],"id":2,"unit":0,"on":1}}
2015.04.12 12:27:11.809 5: pilight(Send): {"action":"send","code":{"protocol":["intertechno_old"],"id":2,"unit":0,"on":1}}
2015.04.12 12:27:11.813 5: pilight(Send): RCV -> {"status":"success"}
2015.04.12 12:27:11.870 4: pilight(SendDone): message successfully send
2015.04.12 12:27:12.270 4: pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch_old","message":{"id":2,"unit":0,"state":"on"},"repeat":1,"uuid":"0000-00-00-63-b5e190"}
2015.04.12 12:27:12.334 5: pilight dispatch SWITCH,intertechno_switch_old,2,0,on
2015.04.12 12:27:12.335 4: pilight_switch_Parse: RCV -> SWITCH,intertechno_switch_old,2,0,on
2015.04.12 12:27:12.391 3: pilight: Unknown code SWITCH,intertechno_switch_old,2,0,on, help me!
@pattex
Sorry mein Fehler. Brands muss in diesem Fall lauten: arctech_switch:intertechno oder spezieller arctech_switch_old:intertechno_old
Alternativ könntest du statt intertechno(_old) auch kaku_switch(_old) probieren.
Dann muss brands so gesetzt werden: arctech:kaku
Risiko
@Risiko
mit intertechno / intertechno_old hatte ich kein Glück
2015.04.12 13:20:31.763 4: pilight(Write): RCV (pilight_switch) -> BUERO_CHARGERS,on
2015.04.12 13:20:31.764 4: pilight(Write): {"action":"send","code":{"protocol":["intertechno_old"],"id":2,"unit":0,"on":1}}
2015.04.12 13:20:31.765 5: pilight(SendNonBlocking): [1] {"action":"send","code":{"protocol":["intertechno_old"],"id":2,"unit":0,"on":1}}
2015.04.12 13:20:31.794 5: pilight(Send): {"action":"send","code":{"protocol":["intertechno_old"],"id":2,"unit":0,"on":1}}
2015.04.12 13:20:31.797 5: pilight(Send): RCV -> {"status":"success"}
2015.04.12 13:20:31.852 4: pilight(SendDone): message successfully send
2015.04.12 13:20:32.254 4: pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch_old","message":{"id":2,"unit":0,"state":"on"},"repeat":1,"uuid":"0000-00-00-63-b5e190"}
2015.04.12 13:20:32.314 3: pilight(Parse): unknown protocol -> intertechno_old
Allerdings hat es mit der Umstellung des Protokolls im Device auf kaku_switch / kaku_switch_old funktioniert. Das ist für mich soweit OK, allerdings glaube ich das da irgendwo bei dem intertechno kram der Wurm drin ist.
@pattex
Danke fürs Testen. Bei intertechno_old war noch ein Fehler bzw. hat noch gefehlt.
Habe ich gefixt.
Risiko
@risiko: Ich hatte das gleiche "intertechno_old"-Problem wie pattex. Dein Fix funktioniert. Vielen Dank für die pilight-Module und Deine Arbeit!
@risiko
Ich habe noch ein weiteres Problem :P
Ich nutze eine Struktur die 3 Rolläden gleichzeitig schaltet. Eine Davon wird leider nicht geschaltet.
2015.04.12 20:25:28.002 4: pilight(Write): RCV (pilight_switch) -> BEDROOM_SHUTTER,on
2015.04.12 20:25:28.003 4: pilight(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":4461293,"unit":0,"on":1}}
2015.04.12 20:25:28.005 5: pilight(SendNonBlocking): [1] {"action":"send","code":{"protocol":["kaku_switch"],"id":4461293,"unit":0,"on":1}}
2015.04.12 20:25:28.030 5: pilight(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":4461293,"unit":0,"on":1}}
2015.04.12 20:25:28.036 5: pilight(Send): RCV -> {"status":"success"}
2015.04.12 20:25:28.086 4: pilight(Write): RCV (pilight_switch) -> LENA_SHUTTER,on
2015.04.12 20:25:28.088 4: pilight(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":4461911,"unit":1,"on":1}}
2015.04.12 20:25:28.089 5: pilight(SendNonBlocking): [1] {"action":"send","code":{"protocol":["kaku_switch"],"id":4461911,"unit":1,"on":1}}
2015.04.12 20:25:28.090 3: pilight(Write): Blocking Call running - will try it later
2015.04.12 20:25:28.150 4: pilight(Write): RCV (pilight_switch) -> TIMO_SHUTTER,on
2015.04.12 20:25:28.152 4: pilight(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":4461911,"unit":0,"on":1}}
2015.04.12 20:25:28.153 5: pilight(SendNonBlocking): [1] {"action":"send","code":{"protocol":["kaku_switch"],"id":4461911,"unit":0,"on":1}}
2015.04.12 20:25:28.154 3: pilight(Write): Blocking Call running - will try it later
2015.04.12 20:25:28.378 4: pilight(SendDone): message successfully send
2015.04.12 20:25:28.658 5: pilight(SendNonBlocking): [1] {"action":"send","code":{"protocol":["kaku_switch"],"id":4461911,"unit":0,"on":1}}
2015.04.12 20:25:28.683 5: pilight(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":4461911,"unit":0,"on":1}}
2015.04.12 20:25:29.379 5: pilight(Send): RCV -> {"status":"success"}
2015.04.12 20:25:29.386 4: pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":4461293,"unit":0,"state":"on"},"repeat":1,"uuid":"0000-00-00-63-b5e190"}
2015.04.12 20:25:29.444 5: pilight dispatch SWITCH,kaku_switch,4461293,0,on
2015.04.12 20:25:29.445 4: pilight_switch_Parse: RCV -> SWITCH,kaku_switch,4461293,0,on
2015.04.12 20:25:29.782 4: pilight(SendDone): message successfully send
2015.04.12 20:25:30.721 4: pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":4461911,"unit":0,"state":"on"},"repeat":1,"uuid":"0000-00-00-63-b5e190"}
2015.04.12 20:25:30.781 5: pilight dispatch SWITCH,kaku_switch,4461911,0,on
2015.04.12 20:25:30.782 4: pilight_switch_Parse: RCV -> SWITCH,kaku_switch,4461911,0,on
Pilight empängt auch nur 2 Nachrichten
[ Apr 12 20:25:28:30541] pilight-daemon: INFO: new client, ip: 172.25.1.2, port: 47490
279 2511 279 279 279 1395 279 279 279 1395 279 279 279 1395 279 1395 279 279 279 279 279 1395 279 27 9 279 1395 279 279 279 1395 279 1395 279 279 279 279 279 1395 279 279 279 1395 279 279 279 1395 279 279 279 1395 279 279 279 1395 279 1395 279 279 279 279 279 1395 279 279 279 1395 279 1395 279 279 27 9 279 279 1395 279 1395 279 279 279 1395 279 279 279 1395 279 279 279 279 279 1395 279 1395 279 279 279 1395 279 279 279 279 279 1395 279 1395 279 279 279 279 279 1395 279 1395 279 279 279 279 279 139 5 279 279 279 1395 279 279 279 1395 279 279 279 1395 279 9486
[Apr 12 20:25:28:683074] pilight-daemon: INFO: new client, ip: 172.25.1.2, port: 47492
279 2511 279 279 279 1395 279 279 279 1395 279 279 279 1395 279 1395 279 279 279 279 279 1395 279 27 9 279 1395 279 279 279 1395 279 1395 279 279 279 279 279 1395 279 279 279 1395 279 279 279 1395 279 279 279 1395 279 279 279 1395 279 1395 279 279 279 279 279 1395 279 1395 279 279 279 279 279 1395 27 9 1395 279 279 279 279 279 1395 279 1395 279 279 279 279 279 1395 279 1395 279 279 279 279 279 1395 279 1395 279 279 279 1395 279 279 279 1395 279 279 279 279 279 1395 279 1395 279 279 279 279 279 139 5 279 279 279 1395 279 279 279 1395 279 279 279 1395 279 9486
Hier scheint irgendetwas verschluckt zu werden. evtl. wegen den none blocking calls
@pattex
D.h. es werden drei Schaltvorgänge in sehr kurzer Zeit durchgeführt - das hatte ich noch nicht. ???
Normalerweise sollte in diesem Fall eine Warteschlange aufgebaut werden, damit alle Messages raus gehen. Scheinbar wohl doch nicht :(
Kannst du mir zum Nachstellen die Struktur als fhem-konfig-Datei zusenden? Dann versuch ich das mal nach zu stellen.
Kann aber etwas dauern.
Risiko
Hallo,
ich habe auch ein Problem mit Schalten von 3 Dosen gleichzeitig. Siehe hier: http://forum.fhem.de/index.php/topic,36279.msg285897.html#msg285897
Wenn du noch was brauchst zur Diagnose gib ein Zeichen.
Einzeln Schalten klappt jetzt prima ... auch ich danke dir für deine Arbeit, Risiko *Daumenhoch*
Th.
Hallo pattex und update71,
ich habe (hoffentlich) das Problem mit dem Senden von mehreren Befehlen in kurzer Zeit und somit das Auflaufen von Befehlen gefixt.
Somit sollten die Schalter auch in einer Struktur nun funktionieren.
Risiko.
@Risiko
der fix funktioniert soweit. ich habe mit 3 devices probiert und es hat funktioniert. Ich werde morgen mal mit 7 probieren. Falls es nicht läuft werde ich mich noch mal melden.
Hallo Freunde,
bei mir klappt es nun auch (mit 3 Devices). Vielen Dank, Risiko !!!
Schönes Wochenende euch allen :)
Th.
Ich habe nun mit 7 Devices hin und her geschaltet und kann bestätigen das es stabil funktioniert.
Sehr hilfreich wäre eine AutoCreate Implementierung. Pilight bietet über die api eine "Geräteliste" auszulesen. Dann würde es reichen, ein Gerät in pilight einzurichten und fhem würde das übernehmen. Soweit ich weiß gibt es leider nicht den Weg, das die Geräte nur in FHEM verwaltet werden und pilight einfach nur die Kommandos sendet.
Hi,
wenn ich mir ansehe was pilight-receive bei mir alles an Funkverkehr meldet dann bin ich eigentlich froh darüber dass es keine autocreate Funktion gibt ^^.
Pattex, beutzt du pilight und fhem parallel? Ich finde die Einrichtung von Geräten in pilight umständlicher als im fhem über das Modul. Ich habe in pilight überhaupt kein Gerät eingerichtet und finde das gut so. Bei mir läuft der fhem Server mittlerweile auf einer Debian Maschine (im "unbewohneten" Bereich) und der Raspi mit pilight liegt unter dem Sofa und versorgt die Billigsteckdosen in WZ und Küche :) ... die Remoteanbindung funktioniert übrigens auch einwandfrei, Risiko :)
Th.
@Update71
Sorry, gut das wir drüber gesprochen haben :-)
Ich hatte das irgendwie so verstanden, das ich die Geräte in PiLight anlegen muß, damit FHEM sie schalten kann. Evtl. war das vielleicht vor 2 Jahren mal so, als die damit angefangen hatte. Du hast absolut recht, es reicht die Geräte im FHEM anzulegen und im Pilight einfach gar nichts anzulegen. Somit wäre eine AutoCreate Funktion für meinen Anwendungsfall auch nicht sinnvoll.
Dann sind wir uns ja einig :)
Bei Gelegenheit werde ich noch versuchen einen 2. Raspberry woanders im Haus zu platzieren und schauen wie es mit 2 remote Pilights funktioniert :)
Btw.: was nutz ihr als Sender? Ich hab momentan direkt einen Sender und einen Receiver dran. Hatte mehrfach gelesen dass es in Verbindung mit einem Arduino besser laufen soll (,CPU Last, Störungen etc.) nur finde ich da bisher keine Anleitung für Doofe ... ich hab noch nie mit dem flashen von einem Arduino zu tun gehabt ^^. Wenn da mal jemand was für mich hat, wäre ich sehr dankbar.
Th.
Ich habe einen 433Mhz Transmitter irgendwo gekauft (das war damals eine Empfehlung auf der PiLight Seite), den habe ich mit einem starren dünnen Kabel als Antenne ausgestattet und den an den GPIO eines Raspberries angeschlossen. Ich musste nie anlernen, da ich intertechno_old benutzte und die werden per Schalter an den Dosen selber konfiguriert. Ich habe, außer die jetzt gelösten Probleme, nie irgendwelche Stabilitätsprobleme mit dieser Anbindung gehabt. Ich nutzte den PiLight allerdings nicht auf dem gleichen Raspberry auf der ich die FHEM nutze. Ich habe hmland und pilight separiert.
Hallo.
Autocreate für pilight halte ich auch für nicht sinnvoll.
Man empfängt einfach zu viel bzw. meint das pilight. Meine Ignore-List ist schon ziemlich lang, obwohl ich einen Empfangsfilter verbaut habe (zumindest ist dadurch die CPU-Last sehr gering).
Daher habe ich nun die Idee, dass das Basismodul alles ignoriert.
Nur die Protokolle und ID's durch definierte Submodule werden akzeptiert.
Das Ganze natürlich ein- ausschaltbar.
Was meint Ihr, die die Module bereits verwenden, dazu?
Risiko.
Nabend,
das hört sich sehr gut an :) ... Pilight empfängt tatsächlich sehr viel. Bei mir weiß ich nicht mal wo das herkommt ... Nachbarn hab ich hier nicht soo viele, schon garnicht in 433 MHz Reichweite. Um genau zu sein eigentlich KEINEN :D
Risiko, kannst du was zu deinem Empfangsfilter sagen? Ich nehme an du hast einen Arduino Nano dazwischen? Ich habe das bei Pimatic gelesen aber keinen Schimmer wie das funktioniert und zusammengebaut wird ... löten ok aber das ganze Programme erstellen, flashen etc. da bräuchte ich ne Anleitung für Doofe ^^.
Gruß Thomas
Hallo Risiko!
Den Vorschlag finde ich ebenfalls sehr sinnvoll, solange es weiterhin eine Möglichkeit gibt, alles zu empfangen.
Z.B kann man dann Wetterstationen in der Umgebung finden und mitnutzen. ;)
Bzw habe ich Fensterkontakte, von dene ich nicht weiß, was sie funken (waren schon da) und habe so eine Möglichkeit das herauszufinden.
Danke jedenfalls für das super Modul
Chipmunk
Hallo soweit funktioniert es bei mir gut.
Was mich wundert ich muss mit der Fernbedienung auf cs 60 cm bis max 1 m an den Empfänger um das Signal zu empfangen aber ich bekomme einen Haufen anderer Sachen angezeigt.
2015-04-20 00:01:11 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"unit":0,"state":"closed"},"origin":"receiver","protocol":"arctech_contact","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:01:11 pilight_ctrl Funken rcv_raw: {"code":{"id":"F0","unit":48,"state":"off"},"origin":"receiver","protocol":"rev2_switch","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:01:11 pilight_ctrl Funken UNKNOWNCODE SWITCH,rev2_switch,F0,48,off
2015-04-20 00:01:11 pilight_ctrl Funken rcv_raw: {"code":{"id":3,"unit":0,"state":"off"},"origin":"receiver","protocol":"rev3_switch","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:01:11 pilight_ctrl Funken UNKNOWNCODE SWITCH,rev3_switch,3,0,off
2015-04-20 00:01:23 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"unit":0,"state":"closed"},"origin":"receiver","protocol":"arctech_contact","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:01:26 pilight_ctrl Funken rcv_raw: {"code":{"id":4194304,"unit":0,"state":"closed"},"origin":"receiver","protocol":"arctech_contact","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:01:29 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"unit":0,"state":"closed"},"origin":"receiver","protocol":"arctech_contact","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:01:44 pilight_ctrl Funken rcv_raw: {"code":{"id":16384,"unit":0},"origin":"receiver","protocol":"techlico_switch","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:01:44 pilight_ctrl Funken UNKNOWNCODE SWITCH,techlico_switch,16384,0,
2015-04-20 00:01:50 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"temperature":-6777,"humidity":0,"battery":1,"channel":1},"origin":"receiver","protocol":"tfa","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:01:50 pilight_ctrl Funken UNKNOWNCODE PITEMP,tfa,0,-6777,0
2015-04-20 00:01:57 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"temperature":0,"humidity":0,"battery":0},"origin":"receiver","protocol":"teknihall","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:01:57 pilight_ctrl Funken UNKNOWNCODE PITEMP,teknihall,0,0,0
2015-04-20 00:02:09 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"all":1,"state":"on"},"origin":"receiver","protocol":"cleverwatts","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:02:09 pilight_ctrl Funken UNKNOWNCODE SWITCH,cleverwatts,0,all,on
2015-04-20 00:02:09 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"unit":0,"state":"off"},"origin":"receiver","protocol":"rev3_switch","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:02:09 pilight_ctrl Funken UNKNOWNCODE SWITCH,rev3_switch,0,0,off
2015-04-20 00:02:14 pilight_ctrl Funken rcv_raw: {"code":{"id":4,"state":"off"},"origin":"receiver","protocol":"ehome","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:02:22 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"unit":0,"state":"closed"},"origin":"receiver","protocol":"arctech_contact","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:02:26 pilight_ctrl Funken rcv_raw: {"code":{"id":4096,"unit":0,"state":"closed"},"origin":"receiver","protocol":"arctech_contact","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:02:43 pilight_ctrl Funken rcv_raw: {"code":{"id":512,"unit":0,"state":"closed"},"origin":"receiver","protocol":"arctech_contact","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:02:46 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"all":1,"state":"on"},"origin":"receiver","protocol":"cleverwatts","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:02:46 pilight_ctrl Funken UNKNOWNCODE SWITCH,cleverwatts,0,all,on
2015-04-20 00:02:46 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"unit":0,"state":"off"},"origin":"receiver","protocol":"rev3_switch","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:02:46 pilight_ctrl Funken UNKNOWNCODE SWITCH,rev3_switch,0,0,off
2015-04-20 00:02:47 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"temperature":0,"humidity":0,"battery":0},"origin":"receiver","protocol":"teknihall","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:02:47 pilight_ctrl Funken UNKNOWNCODE PITEMP,teknihall,0,0,0
2015-04-20 00:02:48 pilight_ctrl Funken rcv_raw: {"code":{"id":"F0","unit":4,"state":"on"},"origin":"receiver","protocol":"rev1_switch","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:02:48 pilight_ctrl Funken UNKNOWNCODE SWITCH,rev1_switch,F0,4,on
2015-04-20 00:02:48 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"unit":8,"state":"off"},"origin":"receiver","protocol":"arctech_switch_old","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:02:48 pilight_ctrl Funken UNKNOWNCODE SWITCH,arctech_switch_old,0,8,off
2015-04-20 00:02:48 pilight_ctrl Funken rcv_raw: {"code":{"id":256,"unit":0},"origin":"receiver","protocol":"beamish_switch","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:02:48 pilight_ctrl Funken UNKNOWNCODE SWITCH,beamish_switch,256,0,
2015-04-20 00:02:49 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"unit":0,"state":"closed"},"origin":"receiver","protocol":"arctech_contact","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:02:59 pilight_ctrl Funken rcv_raw: {"code":{"systemcode":0,"unitcode":0,"state":"on"},"origin":"receiver","protocol":"elro_he","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:02:59 pilight_ctrl Funken UNKNOWNCODE SWITCH,elro_he,0,0,on
2015-04-20 00:02:59 pilight_ctrl Funken rcv_raw: {"code":{"systemcode":15,"unitcode":15,"state":"on"},"origin":"receiver","protocol":"home_easy_old","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:03:04 pilight_ctrl Funken rcv_raw: {"code":{"id":1050624,"unit":0,"state":"closed"},"origin":"receiver","protocol":"arctech_contact","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:03:09 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"temperature":0,"humidity":0,"battery":0},"origin":"receiver","protocol":"teknihall","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:03:09 pilight_ctrl Funken UNKNOWNCODE PITEMP,teknihall,0,0,0
2015-04-20 00:03:16 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"temperature":0,"humidity":0,"battery":0},"origin":"receiver","protocol":"alecto_ws1700","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:03:16 pilight_ctrl Funken UNKNOWNCODE PITEMP,alecto_ws1700,0,0,0
2015-04-20 00:03:25 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"unit":0,"state":"closed"},"origin":"receiver","protocol":"arctech_contact","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:03:31 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"temperature":-6777,"humidity":3200,"battery":1,"channel":1},"origin":"receiver","protocol":"tfa","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:03:31 pilight_ctrl Funken UNKNOWNCODE PITEMP,tfa,0,-6777,3200
2015-04-20 00:03:44 pilight_ctrl Funken rcv_raw: {"code":{"version":40832,"lpf":150,"hpf":286720},"origin":"receiver","protocol":"pilight_firmware","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:03:50 pilight_ctrl Funken rcv_raw: {"code":{"id":1,"temperature":0,"humidity":0,"battery":0},"origin":"receiver","protocol":"auriol","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:03:50 pilight_ctrl Funken UNKNOWNCODE PITEMP,auriol,1,0,0
2015-04-20 00:04:10 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"temperature":0},"origin":"receiver","protocol":"alecto_wsd17","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:04:10 pilight_ctrl Funken UNKNOWNCODE PITEMP,alecto_wsd17,0,0,
2015-04-20 00:04:16 pilight_ctrl Funken rcv_raw: {"code":{"id":"F0","unit":0,"state":"off"},"origin":"receiver","protocol":"rev2_switch","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:04:16 pilight_ctrl Funken UNKNOWNCODE SWITCH,rev2_switch,F0,0,off
2015-04-20 00:04:16 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"unit":0,"state":"off"},"origin":"receiver","protocol":"rev3_switch","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:04:16 pilight_ctrl Funken UNKNOWNCODE SWITCH,rev3_switch,0,0,off
2015-04-20 00:04:16 pilight_ctrl Funken rcv_raw: {"code":{"id":1,"temperature":0,"humidity":0,"battery":0},"origin":"receiver","protocol":"auriol","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:04:16 pilight_ctrl Funken UNKNOWNCODE PITEMP,auriol,1,0,0
2015-04-20 00:04:22 pilight_ctrl Funken rcv_raw: {"code":{"systemcode":0,"unitcode":0,"state":"on"},"origin":"receiver","protocol":"elro_he","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:04:22 pilight_ctrl Funken UNKNOWNCODE SWITCH,elro_he,0,0,on
2015-04-20 00:04:22 pilight_ctrl Funken rcv_raw: {"code":{"systemcode":31,"unitcode":31,"state":"on"},"origin":"receiver","protocol":"elro_hc","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:04:22 pilight_ctrl Funken UNKNOWNCODE SWITCH,elro_hc,31,31,on
2015-04-20 00:04:22 pilight_ctrl Funken rcv_raw: {"code":{"systemcode":0,"unitcode":0,"state":"on"},"origin":"receiver","protocol":"pollin","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:04:22 pilight_ctrl Funken UNKNOWNCODE SWITCH,pollin,0,0,on
2015-04-20 00:04:24 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"temperature":0,"humidity":0,"battery":0},"origin":"receiver","protocol":"teknihall","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:04:24 pilight_ctrl Funken UNKNOWNCODE PITEMP,teknihall,0,0,0
2015-04-20 00:05:13 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"temperature":0},"origin":"receiver","protocol":"alecto_wsd17","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:05:13 pilight_ctrl Funken UNKNOWNCODE PITEMP,alecto_wsd17,0,0,
2015-04-20 00:05:38 pilight_ctrl Funken rcv_raw: {"code":{"id":6,"unit":5,"state":"off"},"origin":"receiver","protocol":"conrad_rsl_switch","uuid":"0000-00-00-56-7f74db","repeats":1}
2015-04-20 00:05:38 pilight_ctrl Funken UNKNOWNCODE SWITCH,conrad_rsl_switch,6,5,off
2015-04-20 00:05:54 pilight_ctrl Funken rcv_raw: {"code":{"id":0,"temperature":0,"humidity":0,"battery":0},"origin":"receiver","protocol":"teknihall","uuid":"0000-00-00-56-7f74db","repeats":1}
Wie kann das sein? Mit der Fernbedienung kann ich aus jeder Ecke meiner Wohnung die Funk Steckdosen schalten. Auch mit dem Raspberry kann ich alle meiner Steckdosen schalten aber das Signal der Fernbedienung bekomme ich nur in Fhem rein wenn ich max 60 cm bis 1 m vom Raspberry weg stehe
würde auch gerne Funk Temperatur Sensoren und Funk Tür Fensterkontakte nutzen was so nicht geht.
Darf ich blöd nachfragen, wann es in den Contrib oder in den final FHEM-Ordner gelangt? 8)
Werde die Tage nochmal pilight installieren und deine Module testen.
@Hauswart
Ja demnächst. Hoffe eher früher als später. :D
Bin dran.
Risiko.
Hallo.
Ich denke, dass durch Rauschen pilight scheinbar so viel empfängt.
Das mit den Empfängern ist in diversen Foren und Blogs schon immer ein Thema.
Hier meine aktuelle Hardware zur Info:
- SMA Antenne 433MHz - 2L - bestellt bei OCTAMEX (sehr zu empfehlen)
- Sender, Empfänger: Geeetech 433Mhz Superheterodyne 3400RF (ebay)
- Empfangsfilter: ATTiny45 (https://github.com/pilight/pilight_firmware)
Alle Teile passen bei einem B+ prima mit ins Gehäuse und die Antenne kann einfach am Gehäuse durch ein Loch montiert werden.
Bei den Empfängern habe ich verschiedene getestet (XY-MK-5V mit Filter, Aurel aber ohne Filter) und bin dann beim Superheterodyne geblieben.
Wollte auch den Aurel mal mit Filter testen, bin ich aber noch nicht dazu gekommen.
Trotz Empfehlung im pilight Forum gpio bei einem Filter zu verwenden, benutze ich Lirc als SW-Empfangsmodul (config.json).
Damit kommt meiner Meinung nach weniger Müll (falsch erkannte Sender) rein.
"hardware": {
"433lirc": {
"socket": "/dev/lirc0"
}
}
Risiko
Hmm hört sich eigentlich gut an aber mein englisch ist nicht mehr das beste. Werde es erstmal mit einem Empfänger aus der Wetterstation versuchen wenn es damit nicht besser ist versuche ich nen superheterodeny da ich das mit dem atiny45 noch nicht recht verstehe.
Halo zusammen,
bekomme folgendes Reading
rcv_raw
{"message":{"systemcode":2066937035,"all":1,"state":"off"},"origin":"receiver","protocol":"elro_300","uuid":"0000-00-00-51-94a9c1","repeats":4}
ich bekomme es einfach nicht geschaft meine Terassenlampe zu schalten. Mit der beiliegenden Fernbedienung von HomeEasy HE 301EU wird zwar der Status in FHEM aktualisiert aber wenn ich es aus FHEM schalten will passiert nichts
define Terassen_Lampe piligth_switch elro_300 2066937035 all ist meine Definition..
Bitte helft mir. Hoffe doch ich muss jetzt nicht extra ein RFXTRX kaufen.
Gruß
Yves
@lulli
all für eine Gruppe wird nicht unterstützt.
Du musst eine Zahl als unitcode verwenden.
Risiko
Bei pilight-receive wird mir leider nur all angezeigt und kein unitcode. Wie bekommen ich den raus
@lulli
Wie du an den richtigen unitcode kommst, weiß ich leider auch nicht.
Habe selber keine Hardware, die das elro_300-Protokoll verwendet.
Hast du es mal mit Null oder Eins probiert?
Ist es ein ähnliches Problem wie hier von tealc beschrieben:
http://forum.fhem.de/index.php/topic,34632.msg276506.html#msg276506
Wenn es mit all für Senden und Empfangen geht, lässt sich noch was machen.
Risiko
Ich habe ein komisches Problem.
Via FHEM oder Konsole kann ich damit meine Intertek Steckdose einschalten:
pilight-send -p elro_800_switch -s 31 -u 1 -t
Aber ausschalten mit -f anstatt -t geht nicht? Ich bin mir 100% sicher, dass es vor zwei Tagen im FHEM mit genau dem gleichen Befehl aber schon einmal ging.... :-D
Hallo @all
Module kommen ab heute per update.
Risiko
Hallo das heißt einfach nur fhem updaten und die Module sind da? Muss ich das update auch machen wenn ich deine Module aus Beitrag 1 schon nutze
Zitat von: Tueftler1983 am 26 April 2015, 10:58:53
Hallo das heißt einfach nur fhem updaten und die Module sind da?
Ja genau. Immer ein Tag später nachdem ich Änderungen einpflege.
Zitat von: Tueftler1983 am 26 April 2015, 10:58:53
Muss ich das update auch machen wenn ich deine Module aus Beitrag 1 schon nutze
Aktuell gibt es noch keine Änderungen.
Risiko.
Freue mich auf die Integration von Funk Temperatur sensoren
Vielen Dank auch von meiner Seite für die neuen Module. Ich bereite gerade den Wechsel von den alten PILIGHT Modulen zu den neuen hier.
Ich habe gerade ein Problem bei mir festgestellt. Sobald ich dem Attribut IGNORE dem Device pilicht_ctrl zuweise, verschwindet dieser von der WEb Oberfläche.
Ich komme dann leider nur noch per fhem.cfg an die Definition.
Kann mir jemand helfen?
vielen dank
Hallo Roger97
kann ich leider nicht nachvollziehen. An meinen beiden Systemen ist alles i.O.
Risiko.
Gleiches bei mir. Attribute ignore gesetzt und ist nun unsichtbar bei mir. Geloggt wird weiterhin?
Hi zusammen,
ich bin relativ neu in der FHEM-Ecke. Gestern bin ich der Suche nach einer Möglichkeit meinen Intertechno Funkschalter (http://www.bauhaus.info/funkstecker/intertechno-funk-wandsender-ywt-8500-/p/12148726?continueUrl=/funkstecker/c/10000334&activeCategory=10000334) zu integrieren auf das Pilight-Modul gestoßen.
Die Integration als On-/Off-Schalter hat auch super funktioniert. Allerdings würde ich auch gerne die Dimm-Funktion benutzen.
Über plight-receive wird mir der Dimm-Lvl über das Attribut "repeats" angezeigt. Allerdings scheint mir pilightCtrl dieses Attribut beim parsen der Nachricht wieder zu verwerfen.
2015.04.28 21:19:41 5: Notify loop for pilightCtrl rcv_raw: {"message":{"id":0,"unit":7,"state":"on"},"origin":"receiver","protocol":"arctech_switch_old","uuid":"0000-00-00-58-78a7c5","repeats":17}
2015.04.28 21:19:41 5: pilightCtrl dispatch SWITCH,intertechno_old,0,7,on
Gibt es irgend eine Möglichkeit die Anzahl der repeats auf das Dimmlevel zu mappen?
Edit:
Ich hab das "repeat" jetzt über das eventMap-Attribut auf "dimlevel" geändert. Das Resultat bleibt aber unverändert.
2015.04.28 22:15:35 5: Notify loop for pilightCtrl rcv_raw: {"message":{"id":0,"unit":7,"state":"off"},"origin":"receiver","protocol":"arctech_switch_old","uuid":"0000-00-00-58-78a7c5","dimlevel":2}
2015.04.28 22:15:35 5: pilightCtrl dispatch SWITCH,intertechno_old,0,7,off
Was mich auch ein wenig wundert ist, dass nach dem Dispatch ein "SWITCH" steht und kein "DIMMER".
In der Config habe ich den Dimmer so angelegt 'define Dimmer pilight_dimmer arctech_switch_old 0 7'
Edit 2:
Hab mir das ganze jetzt nochmal in morgendlicher frische angeschaut. Wenn ich das Protokoll von "arctech_switch_old" auf "dimmer" scheint das ganze zumindest vom Webinterface aus zu funktionieren. Ob der Funkschalter damit auch funktioniert kann ich heute Abend berichten. Wenn ich den code im pilight_ctrl richtig lese ist das dimmer-Protokoll auch das einzige, dass tatsächlich den erkannten dim-level weiterreicht. ist das so gewollt?
@Roger79 und Hauswart
Weiß jetzt was ihr meint ;)
Ignore ist bereits vergeben (komplettes Device - notify, list, etc. ignorieren)
Habe das Attribut in ignoreProtocol umbenannt.
Ab morgen per update.
Risiko.
Hallo shelm,
intertechno_old ist kein Dimmer.
Wie oft eine Nachricht (repeats) rein kommt, hat nichts mit einem Dimmer zu tun.
Aktuell unterstützt pilight glaube ich nur Intertechno\Kaku Dimmer (neues Protokoll - selbstlernend)
http://wiki.pilight.org/doku.php/protocols#dimmers
und dafür ist das Modul pilight_dimmer da.
Bei einem Dimmer wird der Dimlevel im Protokoll mit übertragen.
Die aktuellen Intertechno Sender können keinen Dimlevel direkt senden.
Mit pilight geht das und die Empfänger (Dimmer) verstehen das auch. Für den ITDM-250 kann ich das bestätigen.
Soll heißen, mit einem Intertchno-Sender kann man nur eine "Dimmer-Fahrt" beim Empfänger Starten und Stoppen.
Daher ist der Sender auch nur ein Schalter!!!!!
Den Dimlevel bei einem Stop der "Dimmer-Fahrt" bekommt man eben nicht übermittelt.
Risiko.
Hi Risiko,
danke für die Antwort. Da hab ich mich wohl vom Werbeversprechen blenden lassen ohne vorher nochmal genau zu recherchieren :D
Ich versuch heute Abend trotzdem mal, ob ich nicht die empfangenen Repeats von pilight in ein Dimm-Level übersetzen kann. Sprich gedrückt halten des On-Schalters = erhöhung des Dimlevels und andersrum für Off. Nachdem ich den Schalter eh nur für eine Dimmung mit Sichtkontakt zur Lichtquelle verwenden möchte wäre das eine ausreichende Lösung für mich.
Hi shelm,
das wird meiner Meinung nach nicht funktionieren, aber viel Glück.
Es ist egal wie lange man mit dem Sender "On" sendet und somit die Repeats erhöht. Die "Dimmer-Fahrt" wird beim 2. "On" gestartet wird es mit "OFF" wieder gestoppt. Währenddessen dimmt der Empfänger von Min nach Max und wieder von Max nach Min und so weiter.
Aber vielleicht ist es bei dir auch anders.
Risiko.
Hallo Risiko,
danke für die schnelle Hilfe mit dem Ignore.
Gruß
Roger79
Hallo Risiko,
ist es möglich raw code mit den Modulen zu senden?
Grüße,
Andi2015
@Andi2015
Nein. Aktuell wird Raw Code nicht unterstützt.
Wüste jetzt spontan auch nicht, für was man das benötigen würde.
Risiko.
Schade,
soweit ich weiß gibt es für das elro_flamingo Protokoll noch keine möglichkeit ohne raw-code zu schalten.
Grüße,
Andi2015
@Andi2015
Da hast du wohl recht. Ist aber (soweit ich das sehe) in Arbeit bzw. ist ähnlich\gleich dem Mumbi Protokoll.
Risiko.
Zitat von: Risiko am 17 April 2015, 22:08:05
Hallo pattex und update71,
ich habe (hoffentlich) das Problem mit dem Senden von mehreren Befehlen in kurzer Zeit und somit das Auflaufen von Befehlen gefixt.
Somit sollten die Schalter auch in einer Struktur nun funktionieren.
Risiko.
Hallo Risiko,
wo lag denn der Fehler bei diesem Problem? Rein aus Interesse. Ich hatte dieses Problem auch und hab schon begonnen zu debuggen, vor allem in Richtung Funktion "pilight_ctrl_SendNonBlocking". Die "send_data" Befehle wurden bei mir nicht abgearbeitet, es kamen immer nur neue dazu.
Besten Dank und eine gute Woche
raspberry
Hallo raspberry,
ja genau. Das war das Problem.
Darauf hin habe ich das Handling mit der Warteschlange komplett umgestellt.
Wieso verwendest du nicht einfach den letzten Stand?
Risiko.
Kann das sein, dass durch diese Modulsammlung das bisherige Pilight-Modul geschrottet wird? Seit dem dazugehörigen FHEM-Update kann ich meine Steckdosen nicht mehr schalten.
Die Fehlermeldung im Log verweist auf folgenden Issue: https://github.com/andreas-fey/fhem-pilight/issues/3
Versuche ich nun hierauf zu wechseln, so scheitere ich bei
define pi_ctrl pilight_ctrl localhost:5000 5.0
mit
"cannot load modul pilight_ctrl"
---
Nachtrag:
1) pilight-daemon war weg
2) json nachinstalliert
Alles weg.
Hallo Funk.Odyssey,
1. das 98_pilight.pm Modul bleibt unangetastet. Die Module xx_pilight_yy haben da keinen Einfluss
2. Das wollte ich dir eben als Lsg. schreiben
Prima. Scheint ja jetzt zu funktionieren!? Viel Spaß.
Risiko
Hi,
sieht sehr interessant aus das Projekt ;) Dazu habe ich einige Fragen:
1. Wird es noch eine WikiSeite geben? Auf die erste Suche habe ich nichts gefunden
2. Ist es nur für Raspberry verfügbar?
3. z.Z. habe ich einen RfxTRX von RFXcom. Damit empfange ich jede Menge Temp/Luftfeuchtesensoren TX3-TH (http://www.amazon.de/TX-3-TH-Ersatz-Aussensender-f%C3%BCr-8610/dp/B001IAG1LS) sowie FunkRauchmelder FA20RF (http://www.thiecom.de/elro-fa20rf-rauchmelder-funk.html). Kann ich den RFXTRX durch Pilight ablösen?
4. Ist immer noch der originale PiLight Deamon als BackgroundProzess nötig oder ist alles in FHEM abgewickelt (analog wie ein CUL - da gibt es auch keinen Background Prozess)
Hi Tobias
1. Wenn ich mal viel viel Zeit habe. :( Meiner Meinung nach bekommt man alles aus den commandref raus
2. Es sollte auf allen System laufen, auf denen pilight und FHEM läuft.
3. Es kommt darauf an, ob pilight all deine Hardware unterstützt. Wenn es mit dem RFXTRX funktioniert, warum wechsel. Ist evtl. wegen 4. sogar die bessere Lösung
4. piligtht-daemon wird zwingend benötigt. Die Module kommunizieren nur mit dem daemon. Eine Konfiguration für speziellen Hardware ist in pilight aber nicht notwendig.
Risiko.
Hi,
also zu allererst ein großes Lob, super Arbeit. Ende letzten Jahres habe ich schon mal nach einer einfachen pilight-Integration geschaut und war geknickt weil es nix gab. Und nun habe ich gestern durch Zufall deine Module gesehen - Bingo, das habe ich gesucht. Ich habe nun ein paar Detailfragen:
1. ignoreProtocol:
Attribut: ignoreProtocol
Wert: alecto_wsd17
Trotzdem wird mein Logfile mit Einträgen gefüttert.
2015.05.07 20:33:10 3: pilight(Parse): ERROR no or unknown id {"code":{"temperature":1801,"humidity":550,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0341-91-45-48-554848","repeats":6}
2015.05.07 20:33:10 3: pilight: Unknown code PITEMP,alecto_wsd17,3509,255,, help me!
Wie kann ich das korrigieren und mehrere Protokolle angeben?
2. Wie kann ich die Messwerte anpassen. Meine Temperatursensoren senden die Daten ohne Kommastelle, also eine Zehnerpotenz zu hoch. 239 °C im Wohnzimmer sind mir dann doch etwas zu warm, wie kann ich das korrigieren?
rcv_raw {"code":{"id":1296,"temperature":239,"humidity":370,"battery":1},"origin":"receiver","protocol":"alecto_ws1700","uuid":"0341-91-45-48-554848","repeats":1}
3. Ich kann mit der GUI meinen "Intertechno Funk- Jalousieschalter CMR 500" steuern (via intertechno_old). Der Status wird richtig geschalten. Wenn ich mit meinem "Intertechno YWT-8500 Funk-Wandsender" den Rolladen schließe, wird der Statuswechsel nicht vom pilight-control registriert und der Status ist bleibt "open". Bei pimatic und Verbindung mit pilight hat das funktioniert.
In FHEM bin ich blutiger Anfänger, arbeite erst seit Montag damit. Verzeih mir also bitte die Fragen, falls sie zu easy sind ???
Viele Dank für Deine Hilfe, Stephan
Hallo StG (DD)
1. wenn du alecto_wsd17 komplett ignorieren willst, muss es alecto_wsd17:* heißen
2. Aktuell geht das nicht. Ich habe auch alecto_ws1700 Sensoren und bekomme "richtige" Werte. Evtl mal pilight aktualisieren bzw. nightly build testen.
3. Wahrscheinlich muss hier das Attribut brands richtig gesetzt werden. Hängt davon ab, was pilight beim Empfang als Protokoll meldet. Am Besten mal mit pilight-receive schauen oder verbose in pilight_ctrl auf 5 stellen und im Log nachsehen.
Risiko
Hallo Risiko,
sehr schönes Modul, habe es sofort zum laufen bekommen.
Allerdings habe ich einen Baumarktdimmersatz von TCM, der zwar von pilight unterstützt wird, aber nicht von Deinem Modul.
Die 4 Kanäle (unit 0-3) mit ein/aus Taste werden als quigg_gt7000 mit state on/off erkannt.
Weiterhin gibt es auf der Fernbedienung eine up/down Wippe, die je nach zuvor gedrücktem Kanal ein hoch und runterdimmen ermöglicht. Der state ist dann aber up/down.
Ich habe testweise in Zeile 594 von 10_pilight_ctrl.pm
case m/quigg_screen/ {$protoID = 1;}
case m/quigg_gt7000/ {$protoID = 1;}
eingefügt.
Das funktioniert schonmal teilweise.
Mit
define test01 pilight_switch quigg_gt7000 576 0
define test01 pilight_switch quigg_screen 576 0
habe ich 2 Testdevices angelegt.
Die Ferbedienungssignale werden korrekt angezeigt. (on/off für quigg_gt7000 und up/down für quigg_screen)
Das schalten aus dem Modul heraus funktioniert für on/off auch.
Für quigg_screen funktioniert das leider noch nicht. Man kann ja auch nur set on/off auswählen.
pilight-send -p quigg_screen -i 576 -u 1 -f und pilight-send -p quigg_screen -i 576 -u 1 -t funktionieren.
Kannst du das bitte noch implementieren?
grüße
Klaus
Hallo Risiko,
zuerst mal vielen Dank für Deine hervorragende Arbeit mit diesem Modul!
Ich habe ein Problem mit "ignoreProtocol" und zwar empfängt mein Pilight viele Falsche IDs. Ich könnte natürlich jede ID einzeln ignorieren, aber dies wären sehr viele. Mit pilight-receive empfange ich auch all diese Falschen IDs. Es sind offensichtlich Falsche da die Messwerte alle übereinstimmen. Nebenbei, es liegt nicht am Protokoll, die gleichen Probleme habe ich auch mit dem originalen alecto_ws1700.
2015.05.08 01:02:34 3: pilight_link: Unknown code PITEMP,alecto_ws1700vz,1434,20.7,58, help me!
2015.05.08 01:03:09 3: pilight_link: Unknown code PITEMP,alecto_ws1700vz,1930,20.7,58, help me!
2015.05.08 01:04:19 3: pilight_link: Unknown code PITEMP,alecto_ws1700vz,1434,20.7,58, help me!
2015.05.08 01:04:19 3: pilight_link: Unknown code PITEMP,alecto_ws1700vz,1422,20.7,58, help me!
2015.05.08 01:04:19 3: pilight_link: Unknown code PITEMP,alecto_ws1700vz,1482,20.7,58, help me!
2015.05.08 01:04:54 3: pilight_link: Unknown code PITEMP,alecto_ws1700vz,1422,20.7,58, help me!
2015.05.08 01:06:04 3: pilight_link: Unknown code PITEMP,alecto_ws1700vz,1930,20.7,58, help me!
2015.05.08 01:06:39 3: pilight_link: Unknown code PITEMP,alecto_ws1700vz,1419,20.7,58, help me!
Gibt es eine andere Möglichkeit, oder habe ich womöglich ein Problem mit Pilight? Kann ich die FHEM Konfiguration so anpassen das nur die parametrierten Protokolle empfangen werden? Funkionieren tut übrigens alles, nur wird mir das FHEM.log vollgeschrieben.
Gruß atommeyer
Hallo klausw
Deine Hardware ist hier http://wiki.pilight.org/doku.php/protocols leider nicht gelistet - jedenfalls nicht als Dimmer.
Der Switch für das Protokoll lässt sich zeitnah einbauen. Sollte kein Problem sein.
Das mit dem Screen ("up/down Wippe") habe ich noch nicht ganz verstanden.
Das scheint was Spezielles zu sein. Den screen auf einen Schalter zu mappen, ist meiner Meinung nach nicht richtig.
Bei mir liefert pilight screen-Messages, wenn man die Taste der Fernbedienung gedrückt hält.
Ich werde mir mal was überlegen. Evtl. Up/Down zum Dimmer hinzufügen. Wird aber etwas dauern.
Könntest du mir bitte mal die Meldungen von pilight-receive beim drücken bzw beim gedrückt halten der Wippe schicken.
Risiko.
@atommeyer
Meiner Meinung nach liegt es an der Hardware - besonders am Rauschen.
Verwendest du einen Filter?
Ich habe auch die Erfahrung gemacht, dass Lirc statt GPIO weniger empfindlich ist.
http://forum.fhem.de/index.php/topic,34632.msg287771/topicseen.html#msg287771
Zitat von: atommeyer am 08 Mai 2015, 08:29:34
Kann ich die FHEM Konfiguration so anpassen das nur die parametrierten Protokolle empfangen werden?
Genau an diesem Thema arbeite ich gerade. Bitte etwas Geduld
Risiko
Auf der ersten Seite des Threads wurde die Frage bereits gestellt, aber ich konnte keine Antwort darauf finden:
Der State der Pilight-Switche bleibt im Status "defined". Gibt es eine Chance, wie man den (wie beim anderen Pilight-Modul) auf on|off setzen kann? Mir ist bekannt, dass es keinen Rückkanal gibt, aber das passte dennoch so gut wie immer.
Danke.
Zitat von: Risiko am 08 Mai 2015, 18:10:03
Hallo klausw
Deine Hardware ist hier http://wiki.pilight.org/doku.php/protocols leider nicht gelistet - jedenfalls nicht als Dimmer.
Der Switch für das Protokoll lässt sich zeitnah einbauen. Sollte kein Problem sein.
Das mit dem Screen ("up/down Wippe") habe ich noch nicht ganz verstanden.
Das scheint was Spezielles zu sein. Den screen auf einen Schalter zu mappen, ist meiner Meinung nach nicht richtig.
Bei mir liefert pilight screen-Messages, wenn man die Taste der Fernbedienung gedrückt hält.
Ich werde mir mal was überlegen. Evtl. Up/Down zum Dimmer hinzufügen. Wird aber etwas dauern.
Könntest du mir bitte mal die Meldungen von pilight-receive beim drücken bzw beim gedrückt halten der Wippe schicken.
Risiko.
Hi Risiko,
Es kann natürlich auch sein, das die Fernbedienung nur zufällig zu dem quigg Kram passt.
habe mal nen Foto der Fernbedienung angehängt
Die aus/ein Tasten oben bringen:
{
"message": {
"id": 3520,
"unit": 0,
"state": "on"
},
"origin": "receiver",
"protocol": "quigg_gt7000",
"uuid": "0000-b8-27-eb-b231f0",
"repeats": 1
}die id ändert sich nach Batteriewechsel oder drücken des Resetknopfes
unit gibts 0-3 je nach reihe
lange drücken sorgt nur dafür, das "repeats" hochzählt
Die aus/ein Tasten unten im Kreis erzeugen die gleiche message.
Die unit entspricht dann der zuletzt Gewählten (durch drücken einer der 8 oberen ein/aus tasten)
Die hell/dimmen Tasten unten im Kreis erzeugen:
{
"message": {
"id": 3520,
"unit": 0,
"state": "up"
},
"origin": "receiver",
"protocol": "quigg_screen",
"uuid": "0000-b8-27-eb-b231f0",
"repeats": 1
}für hell
bzw. "down" für dimmen
lange drücken sorgt auch hier nur dafür, das "repeats" hochzählt
Die unit entspricht auch hier der zuletzt gewählten Zeile (durch drücken einer der 8 oberen ein/aus tasten)
Also für:
{
"message": {
"id": 3520,
"unit": 1,
"state": "down"
},
"origin": "receiver",
"protocol": "quigg_screen",
"uuid": "0000-b8-27-eb-b231f0",
"repeats": 1
}Muss ich zuerst ein oder aus in Zeile 2 Drücken und anschließend die Dimmen Taste.
Dabei dimmt bei jedem Tastendruck die Lampe um 5% runter.
Wenn man gedrückt hält dimmt es halt bis zum loslassen oder bis es aus ist.
pilight-send -p quigg_screen -i 3520 -u 1 -ferzeugt bei pilight-receive das gleiche (als origin sender)
und
pilight-send -p quigg_screen -i 3520 -u 1 -täquivalent den state up
Daher würde ich es nicht direkt als Dimmer bezeichnen, da sich kein Dimmwert einstellen lässt, sonder nur stufenweise hoch/runterdimmen.
Im Grunde würde es reichen, wenn man bei pilight_switch als attribut das up/down wählen könnte.
Ich verstehe sowieso nicht, wieso das nicht einfach mit on/off fuktioniert. Die Befehle mit pilight-send sind doch die gleichen.
Oder läuft das über den webport anders?
Hallo @all
mit ignoreProtocol * wird alles ignoriert, bis auf die Protokoll-ID-Kombinationen durch definierte Submodule.
Außerdem Protokoll quigg_gt* (quigg_gt7000) für Schalter ergänzt.
Ab morgen per update.
Risiko
Hallo Funk.Odyssey,
Zitat von: Funk.Odyssey am 08 Mai 2015, 19:08:53
Der State der Pilight-Switche bleibt im Status "defined".
Nein. Wenn alle i.O. ist, bleibt er das nicht.
So sieht es z.B. für ein Kaku\intertechno_old_Switch aus
Hi klausw,
woher nimmst du die 5% Änderung für ein einmaliges Schalten (up,down) mit quigg_screen?
Da durch quigg_screen up\down gedimmt wird, gehört es eher zum Dimmer. Auch wenn man keinen Dimlevel direkt setzen kann.
Könnte mir folgendes vorstellen (noch nicht 100% sicher).
Erweiterung Dimmer:
Step: Schrittweite (0-kontinuierlich)
ON\OFF (gibt es ja schon): Dimlevel auf 100\0% setzen (evtl. einstellbar)
Up\Down: senden und verändern des Dimlevels um Step
Dimlevel setzen: N mal up\down senden, wenn Dimmer keinen direkten Dimlevel hat
Risiko.
Hi Risiko,
Zitat von: Risiko am 09 Mai 2015, 12:11:18
woher nimmst du die 5% Änderung für ein einmaliges Schalten (up,down) mit quigg_screen?
Habe ich mir aus den Fingern gesaugt ;)
...gerade eben nochmal probiert. Mit 11x kurz auf dimmen drücken ist die Lampe von 100% auf nicht mehr sichtbar gedimmt.
Bei dem zweiten sind es 10 Stufen (ist vermutlich vom Leuchtmittel abhängig)
Zitat von: Risiko am 09 Mai 2015, 12:11:18
Da durch quigg_screen up\down gedimmt wird, gehört es eher zum Dimmer. Auch wenn man keinen Dimlevel direkt setzen kann.
Könnte mir folgendes vorstellen (noch nicht 100% sicher).
Erweiterung Dimmer:
Step: Schrittweite (0-kontinuierlich)
ON\OFF (gibt es ja schon): Dimlevel auf 100\0% setzen (evtl. einstellbar)
Up\Down: senden und verändern des Dimlevels um Step
Dimlevel setzen: N mal up\down senden, wenn Dimmer keinen direkten Dimlevel hat
Die Idee ist super, das hätte ich sonst mit notify und so nachgebastelt.
Aber direkt im Modul ist das eleganter.
Klaus
Zitat von: Risiko am 07 Mai 2015, 21:51:01
Hallo StG (DD)
1. wenn du alecto_wsd17 komplett ignorieren willst, muss es alecto_wsd17:* heißen
2. Aktuell geht das nicht. Ich habe auch alecto_ws1700 Sensoren und bekomme "richtige" Werte. Evtl mal pilight aktualisieren bzw. nightly build testen.
3. Wahrscheinlich muss hier das Attribut brands richtig gesetzt werden. Hängt davon ab, was pilight beim Empfang als Protokoll meldet. Am Besten mal mit pilight-receive schauen oder verbose in pilight_ctrl auf 5 stellen und im Log nachsehen.
Risiko
Hallo Risiko,
viele Dank für Deine Antwort.
1. hat gut funktioniert
2. habe ich ehrlich gesagt noch nicht gemacht (never Change a running System ::)). Steht noch auf meinem Plan,
ich versuche es gerade über stateFormat.. Habe es jetzt über berechnete userReadings hinbekommen :)
3. hat leider nicht funktioniert: brands arctech:intertechno
Der Befehl geht von FHEM/pilight raus via intertechno_old . Der Handsender via arctech_switch_old . Leider spricht das Rolltor nicht an, wenn ich von FHEM/pilight statt intertechno_old den arctech_switch_old als device konfiguriere.
Ideen? Danke Dir, Stephan
Zitat von: StG (DD) am 09 Mai 2015, 23:00:31
Der Befehl geht von FHEM/pilight raus via intertechno_old . Der Handsender via arctech_switch_old . Leider spricht das Rolltor nicht an, wenn ich von FHEM/pilight statt intertechno_old den arctech_switch_old als device konfiguriere.
Ideen? Danke Dir, Stephan
Verstehe leider nicht so richtig, was geht und was nicht. Bitte mal genauer welches Protokoll wie geht bzw. nicht geht und Unterscheidung Senden\Empfangen.
Evtl auch mal hier an Punkt zwei (Update) denken.
Risiko.
Hallo ich habe einen Funk Temperatur Sensor in FHEM log steht dazu folgendes:
2015-05-13 23:58:18 pilight_ctrl Funken rcv_raw: {"code":{"id":1,"temperature":256,"humidity":0,"battery":0},"origin":"receiver","protocol":"auriol","repeats":1}
2015-05-13 23:58:18 pilight_ctrl Funken UNKNOWNCODE PITEMP,auriol,1,256,0
Wie kann ich mir diese Temperatur die noch durch 10 geteilt werden muss in FHEM anzeigen lassen?
StG (DD) hat es mit userreading hin bekommen.
Vielleicht kann er den Code beisteuern.
Wenn mehrere das Problem haben, würde ich einen Faktor für Temperatur in pilight_temp einbauen.
Risiko.
attr <DEVICE> userReadings tmphum { sprintf("%s %s", ReadingsVal("<DEVICE>","temperature",0)/10, ReadingsVal("<DEVICE>","humidity",0)/10) ; }
oder
attr <DEVICE> stateFormat { sprintf("%s °C %s %", ReadingsVal("<DEVICE>","temperature",0)/10, ReadingsVal("<DEVICE>","humidity",0)/10) ; }
@Risiko: Kannst Du bitte noch den Batteriestatus zur Verfügung stellen :)
Zitat von: StG (DD) am 15 Mai 2015, 21:28:13
@Risiko: Kannst Du bitte noch den Batteriestatus zur Verfügung stellen :)
Ab morgen per Update sowie die Möglichkeit mittels dem Attribut 'corrTemp' die Temperatur zu korrigieren z.B. 256, corrTemp=0.1 --> 25.6
Risiko
Hallo Risiko,
bitte auch mit Korrekturfaktor für die Luftfeuchte ::)
Lieben Dank, Stephan
Zitat von: StG (DD) am 16 Mai 2015, 19:48:47
bitte auch mit Korrekturfaktor für die Luftfeuchte ::)
Erledigt. Hatte ich vergessen. Brauche ich selbst ja nicht ;)
Risiko
Hallo risiko
besten Dank für dein Modul.
Ich suche eine Möglichkeit, nicht Schalter und Dimmer mit pilight in fhem zu integrieren sondern PIR-Bewegungsmelder. Diese konnte ich in pilight einhängen und bekomme auch den Empfang hin:
{
"message": {
"id": 16,
"unit": 1,
"state": "on"
},
"origin": "receiver",
"protocol": "arctech_switch_old",
"uuid": "0000-00-00-10-1eee47",
"repeats": 7
}
Biete dein Modul da eine einfache Integration. Damit könnte ich dann sehr einfach diese günstigen PIR-Melder in fhem einbauen.
Besten Dank
MrTom
Hallo habe auch einen Bewegungsmelder integriert. Bekomme von ihm auch nur ein on Signal kein abschalt signal!
Ich habe es mit DOIF gelöst wenn das Signal on vom bewegungsmelder kommt schalte einen Dummy ein, sleep Zeit x dann schalte bewegungsmelder und Dummy aus.
Klappt super
@MrTom
Die Lösung hat dir Tueftler1983 ja vorgegeben.
Man benötigt eigentlich auch nur das Grundmodul pilight_ctrl, indem man das Reading 'rcv_raw' auswertet.
Das ist noch ein vollständiges json-Format.
Risiko
Hallo Risiko,
funktioniert. Sowohl Batteriestatus als auch corrTemp. Fehlt nur noch corrHum :-X
VG, Stephan :D
Zitat von: StG (DD) am 17 Mai 2015, 20:38:05
Fehlt nur noch corrHum :-X
Ab morgen per Update ;)
Hallo Risiko,
ich habe einen 433 MHZ Sender und einen Empfänger an meinen Raspi integriert.
Damit funktioniert auch wunderbar das steuern von Funksteckdosen und das Empfangen von Fernbedienungen mit deinen Modulen.
Nun habe ich auf den pilight_switch ein Notify drauf gelegt, so dass die Funksteckdose automatisch nach zwei Stunden wieder ausgehen soll.
Im Log sehe ich jedoch, dass der notify zweimal aufgerufen wird.
1 x beim Einschalten der Funksteckdose per Web und 1 x wenn das Signal gesendet wird empfängt natürlich pilight_ctrl auch dieses Signal und setzt nochmals in Fhem den gleich Switch.
Hast du eine Idee wie ich das verhindern kann. Das Log läuft ziemlich voll dadurch.
Mit dem Attribut IgnoreProtocoll habe ich genau diese ID mal auseschlossen, da in der CommandRef der Hinweis steht, dass nur eingehende Protokolle damit ignoriert werden.
Das scheint es auch, da die Steckdose noch immer ein und ausgeschaltet wird.
Jedoch wird im Web der pilight_switch nicht mehr geändert und der notify reagiert nun gar nicht mehr.
Viele Grüße
Roger79
Hallo auch hier würde ich sagen könnte ein DOIF helfen habe dieses für verschiedene Sachen genutzt guck mal auf Seite 8 meinen Post zum Bewegungsmelder
@Roger79,
ja das Notify kommt aktuell zwei mal. Das vom WEB ist meiner Meinung nach nicht i.O. bzw. überflüssig.
Weiß aber jetzt spontan auch nicht, wie man das abstellt. Das Notify direkt vom Switch kann man nicht raus nehmen, sonst würde beim Schalten per Fernbedienung kein Notify erzeugt.
Das rausnehmen per ignoreProtocol ist auf jeden Fall nicht der richtige Weg.
Verwendung von event-on-change-reading sollte helfen.
Werde ich bei Gelegenheit mal prüfen.
Risiko
Zitat von: Risiko am 17 Mai 2015, 22:50:57
Ab morgen per Update ;)
Hat auch prima funktioniert. Danke Dir :D
Zitat von: Risiko am 09 Mai 2015, 12:11:18
Erweiterung Dimmer:
ON\OFF (gibt es ja schon): Dimlevel auf 100\0% setzen (evtl. einstellbar)
Up\Down: senden und verändern des Dimlevels um Step
Dimlevel setzen: N mal up\down senden, wenn Dimmer keinen direkten Dimlevel hat
Ich habe die Funktionalität des Dimmers erweitert. Es ist jetzt möglich, den Dimmer um die Screen (up|down) Funktionalität zu erweitern.
Dazu muss bei der Definition das passende Screen-Protokoll mit angegeben werden (2. optionales Protokoll).
Es ist auch möglich, einen Dimmer aus Screen- und Switch-Protokoll zu erstellen. Die Hardware unterstützt in diesem Fall keinen dimlevel direkt (Bezug zu hier: http://forum.fhem.de/index.php/topic,34632.msg293014.html#msg293014).
Beispiele in CommandRef (ab morgen)
Risiko.
Zitat von: Risiko am 20 Mai 2015, 22:11:22
Ich habe die Funktionalität des Dimmers erweitert. Es ist jetzt möglich, den Dimmer um die Screen (up|down) Funktionalität zu erweitern.
Dazu muss bei der Definition das passende Screen-Protokoll mit angegeben werden (2. optionales Protokoll).
Es ist auch möglich, einen Dimmer aus Screen- und Switch-Protokoll zu erstellen. Die Hardware unterstützt in diesem Fall keinen dimlevel direkt (Bezug zu hier: http://forum.fhem.de/index.php/topic,34632.msg293014.html#msg293014).
Beispiele in CommandRef (ab morgen)
Super Sache, das werde ich heute gleich mal testen.
Definiert habe ich es schon einmal und die Botschaften die rausgehen machen einen guten Eindruck :D.
2 Dinge sind mir aufgefallen:
1. eher kosmetisch:
in Zeile 176 und 177 :noArg hinzufügen. Das sorgt dafür, das in der Detailansicht hinter den entsprechenden Werten kein Eingabefeld erscheint.
my $canSet = "on:noArg off:noArg";
$canSet .= " up:noArg down:noArg" if ($hash->{helper}{ISSCREEN});2. up und down setzen das dimlevel korrekt. on und off verändern das dimlevel aber nicht (es sollte dann sicher auf 0 bzw. max gehen)
Wenn ich am schieber einen Wert einstelle wird dann entsprechend des Differenzwertes n mal die up bzw. down Botschaft geschickt?
Hallo klausw
Zitat von: klausw am 21 Mai 2015, 11:18:36
1. eher kosmetisch:
in Zeile 176 und 177 :noArg hinzufügen. Das sorgt dafür, das in der Detailansicht hinter den entsprechenden Werten kein Eingabefeld erscheint.
my $canSet = "on:noArg off:noArg";
$canSet .= " up:noArg down:noArg" if ($hash->{helper}{ISSCREEN});
Ok. Werde ich übernehmen.
Zitat von: klausw am 21 Mai 2015, 11:18:36
2. up und down setzen das dimlevel korrekt. on und off verändern das dimlevel aber nicht (es sollte dann sicher auf 0 bzw. max gehen)
Nein. Ist eigentlich so beabsichtigt, dass on|off nichts am dimlevel ändern. Wenn von off wieder auf on geschalten wird, dann wird der letzte Dimlevel gleich mit gesendet und gesetzt.
Im Falle, dass das Device kein dimlevel kann, könnte man evtl. nochmal überlegen was da sinnvoll ist.
Zitat von: klausw am 21 Mai 2015, 11:18:36
Wenn ich am schieber einen Wert einstelle wird dann entsprechend des Differenzwertes n mal die up bzw. down Botschaft geschickt?
Ja genau. So sollte es sein!
Risiko
Zitat von: Risiko am 21 Mai 2015, 18:24:14
Nein. Ist eigentlich so beabsichtigt, dass on|off nichts am dimlevel ändern. Wenn von off wieder auf on geschalten wird, dann wird der letzte Dimlevel gleich mit gesendet und gesetzt.
Im Falle, dass das Device kein dimlevel kann, könnte man evtl. nochmal überlegen was da sinnvoll ist.
Ahso, jetzt verstehe ich. So ganz rund läuft es noch nicht (was jammern auf hohem Niveau ist ;)).
Der Funkdimmer schaltet bei einem "on" direkt auf 100%. D. h. beim einschalten dürften nur "up"s gesendet werden.
Wenn kein Dimlevel existiert wäre es meiner Meinung nach sinnvoll, es beim einschalten auf Maximum zu setzen.
Auch würde ich vorschlagen, wenn das dimlevel auf 0 gesetzt wird, direkt off zu schicken und evtl. den letzten dimmzustand im dimlevel zu speichern.
Zitat von: Risiko am 21 Mai 2015, 18:24:14
Ja genau. So sollte es sein!
das funktioniert auch so. habe es gerade probiert
super! ;)
@klausw
Ich habe ein paar Kleinigkeiten entsprechend deinen Vorschlägen angepasst.
Anbei schon mal die Version zum Testen. Geht sonst so ins Repository.
Risiko
Zitat von: Risiko am 21 Mai 2015, 20:09:50
@klausw
Ich habe ein paar Kleinigkeiten entsprechend deinen Vorschlägen angepasst.
Anbei schon mal die Version zum Testen. Geht sonst so ins Repository.
Risiko
Hallo Risiko,
habe gerade mal probiert:
wenn man in den details das dimlevel setzt, oder auch andere set's werden die readings nicht aktualisiert
dimlevel auf 0 klappt -> wird direkt ausgeschaltet
set auf on schaltet immer auf 100%
Zitat von: klausw am 21 Mai 2015, 21:45:15
wenn man in den details das dimlevel setzt, oder auch andere set's werden die readings nicht aktualisiert
Kann ich nicht so richtig nachvollziehen. Schaue mirs aber nochmal an
Zitat von: klausw am 21 Mai 2015, 21:45:15
set auf on schaltet immer auf 100%
Dachte es ist so gewollt.
Zitat von: Risiko am 21 Mai 2015, 22:35:12
Kann ich nicht so richtig nachvollziehen. Schaue mirs aber nochmal an
Dachte es ist so gewollt.
Die readings werden nach einem reboot auch wieder aktualisiert. Da ist wohl eher bei mir der Wurm drin.
Ich hatte es anders verstanden. Aber wie es umgesetzt wird ist eigentlich egal.
Im Moment ist ein Problem (ich habe default werte... 15 stufen, stepsize 1):
state ist on / dimlevel auf 15 -> set dimlevel 0 führt zu -> state ist off / dimlevel auf 15
wenn ich jetzt set up mache dann zählt das dimlevel immer höher (über 15) und set dimlevel 15 führt zum ausschalten.
oder
state ist on / dimlevel auf 15 -> set off führt zu -> state ist off / dimlevel auf 15
gleiches Problem
der dimlevel passt nicht mehr
eine Möglichkeit währe es, den dimlevel bei on auf max und bei off auf 0 zu setzen
oder
bei set off den dimlevel beibehalten und bei set on dimlevel * up zu machen (also hochdimmen)
dann ist aber das problem, was man macht, wenn z.B. off ist und dimlevel auch max und man führt set up aus
daher ist es vermutlich am besten bei
set off -> state off / dimlevel off
set on -> state on / dimlevel max
set dimlevel 0 -> state off / dimlevel off
ich hoffe ich habe nix vergessen und dich nicht verwirrt ;)
und Danke füe deine Arbeit :)
Hi.
Das sollte so nicht sein. Wie sind die Attribute dimlevel_max_device, dimlevel_max, dimlevel_step gesetzt?
dimlevel_max_device muss <= dimlevel_max sein.
Komme heut und morgen nicht dazu mir das anzusehen :-[
Risiko.
Zitat von: Risiko am 22 Mai 2015, 18:15:48
Das sollte so nicht sein. Wie sind die Attribute dimlevel_max_device, dimlevel_max, dimlevel_step gesetzt?
dimlevel_max_device muss <= dimlevel_max sein.
beides nicht gesetzt
Zitat von: Risiko am 22 Mai 2015, 18:15:48
Komme heut und morgen nicht dazu mir das anzusehen :-[
Das macht nix. Für den Anfang ist es schon super nutzbar :)
Hi.
V1: dimlevel_max_device und dimlevel_max auf den maximalen Wert z.B. 15 und dimlevel_step auf 1
V2: dimlevel_max auf 100 und dimlevel_step auf 6 bzw 7, so das ca. 15 Abstufungen resultieren.
Risiko.
Hallo,
Zitat von: Risiko am 22 Mai 2015, 22:32:34
V1: dimlevel_max_device und dimlevel_max auf den maximalen Wert z.B. 15 und dimlevel_step auf 1
V2: dimlevel_max auf 100 und dimlevel_step auf 6 bzw 7, so das ca. 15 Abstufungen resultieren.
Ah, ich dachte dimlevel_max_device ist standardmäßig 15, wenn es nicht gesetzt ist
Jetzt bleibts auch bei 15 stehen.
Das einzige was noch fehlt ist ist, das bei off das dimlevel auf 0 gesetzt wird.
Dann sollte alles funktionieren.
Klaus
Zitat von: Risiko am 04 Mai 2015, 18:38:53
ja genau. Das war das Problem.
Darauf hin habe ich das Handling mit der Warteschlange komplett umgestellt.
Wieso verwendest du nicht einfach den letzten Stand?
Hallo Risiko,
vielen Dank für die Antwort! Ich habe die aktuelle Version des Moduls schon verwendet bzw. verwende sie, mich hat nur interessiert ob es wirklich ein Problem mit der Warteschlange war, weil ich damit auch ein paar Stunden verbracht habe. ;-)
Besten Dank und viele Grüße
raspberry
Zitat von: klausw am 22 Mai 2015, 23:04:10
Das einzige was noch fehlt ist ist, das bei off das dimlevel auf 0 gesetzt wird.
Klaus
Hallo Klaus,
anbei eine neue Version zum Vortesten.
Es gibt jetzt die Attribute dimlevel_on und dimlevel_off zum steuern, welcher dimlevel bei on, off eingestellt wird.
Risiko
Hallo Risiko,
hat es einen bestimmten Grund warum in allen Modulen pilight_* im Define das Internal "STATE" mit "defined" belegt wird?
Das hat zur Folge, dass das Readings "state" und das Internal "STATE" inkonsistent werden falls mal FHEM durchgestartet wird oder z. B. direkt in der fhem.cfg per WEB geändert wird.
Ich habe bei mir mal folgende Codingstelle entfernt und Fhem neu gestartet:
$hash->{STATE} = "defined";
Nach dem Neustart wurde STATE korrekt gesetzt und ich sehe wieder meiner Glühbirne anstelle "defined".
Wenn müsste es dann in allen Modulen pilight_* entfernt werden.
Was meinst du dazu?
Viele Grüße
Roger79
Hallo Roger79,
muss ich mir nochmal ansehen.
Nach dem Start ist der Zustand formell nicht bekannt. Die letzte Änderung am Modul ist eben das Anlegen (define). Der State wurde weder von pilight noch von FHEM\User gesetzt.
Ich habe den Mechanismus von FHEM mit save\restore der Zustände beim Restart aber auch noch nicht durchblickt.
Risiko.
Hallo Risiko,
bin erst heute zum testen gekommen.
Zitat von: Risiko am 25 Mai 2015, 10:30:41
anbei eine neue Version zum Vortesten.
Es gibt jetzt die Attribute dimlevel_on und dimlevel_off zum steuern, welcher dimlevel bei on, off eingestellt wird.
Funktioniert immer besser.
Das einzige, was mir auffiel, ist beim setzen des dimlevel auf 0 geht die Lampe sofort aus, und state auf off, das reading dimlevel jedoch bleibt auf dem alten Wert stehen und geht nicht auf 0
gesetzte Attribute:
dimlevel_max_device 15
dimlevel_off 0
dimlevel_on 15
Grüße
Klaus
Hallo Risiko,
vielen Dank schonmal.
Fhem speichert auch die Readings nicht nur die Definitions mit jedem SAVE oder Shutdown, usw., mit den Werten in der Datei fhem.save.
Die dann beim Hochfahren wieder gesetzt werden.
Hier noch ein Link, der ggf. nützlich sein könnte.
http://www.fhemwiki.de/wiki/DevelopmentState (http://www.fhemwiki.de/wiki/DevelopmentState)
Viele Grüße
Roger79
Beim heutigen "apt-get upgrade" habe ich mir Pilight in der Version 7.0 "eingefangen". Ich hab danach festgestellt, dass dein Modul nicht mehr funktioniert. Hast du vor, dies zukünftig anzupassen?
Danke.
Nachtrag: ach, verdammt. Meine config.json war nicht mehr gültig. Schnell die Default-Version um Port 5000 erweitert und schon lief es wieder. API blieb in Fhem bei 6.0.
Zwischen Version 6.0 und 7.0 hat sich die API zum Glück nicht geändert. Jedenfalls hab ich noch nichts festgestellt. Plane aber schon die Module zu pflegen. Das bei einem Update von pilight immer die config flöten geht, ist wirklich etwas nervig.
Risiko
Zitat von: klausw am 27 Mai 2015, 22:41:46
Das einzige, was mir auffiel, ist beim setzen des dimlevel auf 0 geht die Lampe sofort aus, und state auf off, das reading dimlevel jedoch bleibt auf dem alten Wert stehen und geht nicht auf 0
Habe ich gefixt. Ab morgen per update.
Risiko.
Zitat von: Roger79 am 27 Mai 2015, 19:59:59
Ich habe bei mir mal folgende Codingstelle entfernt und Fhem neu gestartet:
$hash->{STATE} = "defined";
Nach dem Neustart wurde STATE korrekt gesetzt und ich sehe wieder meiner Glühbirne anstelle "defined".
Wenn müsste es dann in allen Modulen pilight_* entfernt werden.
Roger79
Ich habe das Problem in alle x_pilight_y Modulen behoben. STATE wird intern (fhem.pl) nur wieder aus fhem.save hergestellt, wenn STATE noch \?\?\? ist.
Zudem ist hier: http://www.fhemwiki.de/wiki/DevelopmentModuleIntro das notwendige X_StateFn nicht beschrieben.
Bei 10_pilight_ctrl war es sogar richtig falsch, dass der STATE und die Readings wieder restauriert worden.
Risiko.
Zitat von: Roger79 am 18 Mai 2015, 09:11:33
Im Log sehe ich jedoch, dass der notify zweimal aufgerufen wird.
1 x beim Einschalten der Funksteckdose per Web und 1 x wenn das Signal gesendet wird empfängt natürlich pilight_ctrl auch dieses Signal und setzt nochmals in Fhem den gleich Switch.
Doppelte Trigger|notify behoben.
Risiko.
Guten Morgen!
Mich plagt ein kleines Problem:
Ich habe pilight definiert, pilight_switch ebenfalls angelegt. Meine ID und Unit eingerichtet, soweit alles fein.
Schalte ich den pilight_switch per DOIF funktioniert auch alles.
Aber beim klick auf on oder off in der Weboberfläche löst keinerlei Reaktion aus.
Bei keinem von 4 definierten Schaltern.
Kennt jemand das Problem?
Andere Frage im Zusammenhang mit Pilight: Mebus Wetterstation, ich würde gern den Sender mitlesen. Weiß jemand ob das Protokoll gemäß http://sourceforge.net/p/rflink/svn/15/tree/Plugins/Plugin_040.c implementiert ist?
Hallo anfichtn
Zitat von: anfichtn am 31 Mai 2015, 07:50:19
Aber beim klick auf on oder off in der Weboberfläche löst keinerlei Reaktion aus.
Kennt jemand das Problem?
Ich kenne es nicht. Kann es leider nicht nachvollziehen. Verwende auch kein DOIF.
Du kannst ja mal verbose auf 4 stellen und dir die Logausgaben ansehen.
Zitat von: anfichtn am 31 Mai 2015, 07:50:19
Andere Frage im Zusammenhang mit Pilight: Mebus Wetterstation, ich würde gern den Sender mitlesen. Weiß jemand ob das Protokoll gemäß http://sourceforge.net/p/rflink/svn/15/tree/Plugins/Plugin_040.c implementiert ist?
Hier http://wiki.pilight.org/doku.php/protocols#weather_stations ist es nicht gelistet. Das muss nichts heißen. Am besten mal im pilight Forum nachsehen\fragen.
Wenn ich das Protokoll kenne, kann ich es einbauen.
Risiko.
Das Protokoll sollte LaCrosse sein....
Problem mit dem letzten Update gelöst. Weshalb kein automatisches Update mehr funktioniert ist eine andere Baustelle.
Fehlt nur noch das passende Protokoll.
Hat noch jemand das Problem, dass FHEM sporadisch abstürzt und nicht mehr erreichbar ist? Erst nach einem reboot geht FHEM wieder. Ich habe festgestellt, dass Pilight bei mir der Übeltäter ist... Nur weiss ich nicht warum.
Ich verwende einen Raspberry mit aktuellem Raspbian.
Zitat von: Hauswart am 04 Juni 2015, 14:28:23
Hat noch jemand das Problem, dass FHEM sporadisch abstürzt und nicht mehr erreichbar ist?
Kenne ich nicht. Habe das System mit pilight seit mehreren Monaten im Dauereinsatz.
Zitat von: Hauswart am 04 Juni 2015, 14:28:23
Ich habe festgestellt, dass Pilight bei mir der Übeltäter ist... Nur weiss ich nicht warum.
Wie hast du das festgestellt?
Ohne weitere Infos kann ich da leider auch nicht helfen.
Zitat von: anfichtn am 31 Mai 2015, 07:50:19
Guten Morgen!
Mich plagt ein kleines Problem:
Ich habe pilight definiert, pilight_switch ebenfalls angelegt. Meine ID und Unit eingerichtet, soweit alles fein.
Schalte ich den pilight_switch per DOIF funktioniert auch alles.
Aber beim klick auf on oder off in der Weboberfläche löst keinerlei Reaktion aus.
Bei keinem von 4 definierten Schaltern.
Kennt jemand das Problem?
Ich hatte das nun auch bereits zweimal. Es wurde über die GUI oder über die FHEM APP keine Reaktion ausgelöst. Manuell über die Bash ging es mit "pilight-send".
Das Control-Device war okay. Ein Reset hat auch nichts geändert. Der Pilight-Dienst wurde auch neu gestartet. Ohne Erfolg.
Erst ein Neustart des FHEM-Services löste das Problem.
Hallo Funk.Odyssey,
danke für die Beschreibung. Was meinst du mit
Zitat von: Funk.Odyssey am 06 Juni 2015, 02:02:48
Das Control-Device war okay. Ein Reset hat auch nichts geändert.
Meinst du mit Reset pilight_ctrl? Welchen Status hatte pilight_ctrl, wo es nicht mehr ging?
Hilfreich wäre, wenn im Fehlerfall verbose in pilight_ctrl auf 5 gesezt wird und ich mal die Log's zu sehen bekomme.
Risiko
Ja, ich meinte "reset pilight_ctrl". Aber nur, um es auszuprobieren. Das Device sah weder merkwürdig aus noch hätte es einen fehlerhaften Status. Es stand ganz normal im Status "opened".
Es hat sich dadurch ja auch nichts geändert. Ich musste FHEM (nicht den Raspberry) neu starten.
FHEK war ganz normal zu bedienen. Jedoch nur nicht die "pilight_switch(e)".
Habe heute einen Fehler im Reset gefixt.
Das Reset hat die Verbindung zu den Submodulen (switch, dimmer, etc.) kaputt gemacht, was erst durch FHEM Neustart bzw. Neuanlegen der Submodule wieder behoben wird.
Das erklärt, warum nach einem manuellem Reset das Schalten aus FHEM nicht mehr funktionierte. Es erklärt aber nicht, wie es dazu kommt, wenn man den Reset nicht manuell auslöst.
Den Reset kann man nach dem Neustart vom pilight-daemon machen. Es wird aber automatisch bei einem disconnect alle 60s ein Verbindungsaufbau neu versucht (wenn Status disconnected).
Risiko.
Danke für das Fixen. Klingt vielversprechend. Vor allem auch die Tatsache, dass das Control-Device sowieso alle 60s die Verbindung zum Daemon sucht.
Ich werde das mal beobachten. Es kann bei mir auch gut sein, dass ich die Reihenfolge nicht beachtet habe und das Control-Device vielleicht sogar erst zurückgesetzt hatte und dann die GUI nicht lief. Lass uns mal warten.
Danke.
Hat jemand ne Ahnung was ich tun kann wenn ich die Fehlermdeldung: "Cannot load module" bekomme?
Ich FHEM update gemacht und habe FHEM auch neu gestartet.
libjson-perl und\oder libswitch-perl nicht installiert?
Risiko
ich bin die Anleitung im Wiki durchgegangen, komplett und da war das dabei es zu installieren.
Ich habe jetzt mit folgenden Befehlen die Dose eingefügt in Fhem:
define Schreibtisch pilight elro_800_switch
attr Schreibtisch systemcode 11
attr Schreibtisch unitcode 1
In Fhem habe ich dann Pilight und Schreibtisch drin. Aber schalten kann ich die Dose nicht. Muss ich Fhem noch irgendwie sagen auf welcher IP sich Pilight befindet? Aber wie gesagt der Befehl pilight_ctrl nimmt er ja nicht.
Moin!
Zitat von: Risiko am 06 Juni 2015, 08:17:30
Hilfreich wäre, wenn im Fehlerfall verbose in pilight_ctrl auf 5 gesezt wird und ich mal die Log's zu sehen bekomme.
Risiko
Log mit verbose 5 werfe ich gleich noch nach, State von pilight_ctrl war zum Fehlerzeitpunkt "0".
[edith]:
2015.06.09 07:14:49.957 4: pilight(Parse): RCV -> {"message":{"id":12,"unit":1,"state":"off"},"origin":"receiver","protocol":"arctech_switch_old","uuid":"0000-98-3b-16-e96c5c","repeats":1}
2015.06.09 07:14:49.960 4: pilight(Parse): intertechno_switch_old:12 not in white list
2015.06.09 07:15:00.005 4: pilight(Write): RCV (pilight_switch) -> SW_Liv_Radio,off
2015.06.09 07:15:00.007 4: pilight(Write): {"action":"send","code":{"protocol":["intertechno_switch"],"id":15742938,"unit":2,"off":1}}
2015.06.09 07:15:00.007 5: pilight(SendNonBlocking): queue size 1
2015.06.09 07:15:00.044 5: pilight(Send): {"action":"send","code":{"protocol":["intertechno_switch"],"id":15742938,"unit":2,"off":1}}
2015.06.09 07:15:00.046 5: pilight(Send): RCV -> {"status":"success"}
2015.06.09 07:15:00.060 4: pilight(SendDone): message successfully send
2015.06.09 07:15:00.517 5: pilight(SendNonBlocking): queue size 0
2015.06.09 07:15:00.900 4: pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":15742938,"unit":2,"state":"off"},"repeat":1,"uuid":"0000-98-3b-16-e96c5c"}
2015.06.09 07:15:00.922 5: pilight dispatch PISWITCH,intertechno_switch,15742938,2,off
2015.06.09 07:15:00.925 4: pilight_switch_Parse: RCV -> PISWITCH,intertechno_switch,15742938,2,off
2015.06.09 07:15:08.005 4: pilight(Parse): RCV -> {"message":{"id":0.0,"temperature":0.0,"humidity":0.0,"battery":0.0},"origin":"receiver","protocol":"teknihall","uuid":"0000-98-3b-16-e96c5c","repeats":1}
2015.06.09 07:15:08.008 4: pilight(Parse): teknihall:0 not in white list
Da hat es noch funktioniert.
2015.06.09 19:29:47.297 4: pilight(Parse): conrad_rsl_switch:6 not in white list
2015.06.09 19:29:47.774 4: pilight(Parse): RCV -> {"message":{"id":"F11","unit":47,"state":"off"},"origin":"receiver","protocol":"clarus_switch","uuid":"0000-98-3b-16-e96c5c","repeats":1}
2015.06.09 19:29:47.777 4: pilight(Parse): clarus_switch:F11 not in white list
2015.06.09 19:30:00.195 1: Time now: 1433871000 - Time desired: 1433873700 - difference: 2700
2015.06.09 19:30:00.247 4: pilight(Write): RCV (pilight_switch) -> SW_Liv_Radio,off
2015.06.09 19:30:00.248 4: pilight(Write): {"action":"send","code":{"protocol":["intertechno_switch"],"id":15742938,"unit":2,"off":1}}
2015.06.09 19:30:00.249 5: pilight(SendNonBlocking): queue size 1
2015.06.09 19:30:00.267 5: pilight(Send): {"action":"send","code":{"protocol":["intertechno_switch"],"id":15742938,"unit":2,"off":1}}
2015.06.09 19:30:00.269 5: pilight(Send): RCV -> {"status":"success"}
2015.06.09 19:30:00.288 4: pilight(SendDone): message successfully send
2015.06.09 19:30:00.758 5: pilight(SendNonBlocking): queue size 0
2015.06.09 19:30:01.123 4: pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":15742938,"unit":2,"state":"off"},"repeat":1,"uuid":"0000-98-3b-16-e96c5c"}
2015.06.09 19:30:01.131 5: pilight dispatch PISWITCH,intertechno_switch,15742938,2,off
2015.06.09 19:30:01.178 4: pilight_switch_Parse: RCV -> PISWITCH,intertechno_switch,15742938,2,off
2015.06.09 19:30:20.157 4: pilight(Parse): RCV -> {"message":{"id":"E3","unit":0,"state":"off"},"origin":"receiver","protocol":"clarus_switch","uuid":"0000-98-3b-16-e96c5c","repeats":1}
2015.06.09 19:30:20.160 4: pilight(Parse): clarus_switch:E3 not in white list
Das hat dann nicht mehr funktioniert.
2015.06.09 20:09:48.911 4: pilight(Parse): intertechno_switch_old:0 not in white list
2015.06.09 20:09:56.080 4: pilight(Parse): RCV -> {"message":{"id":0.0,"temperature":0.0,"humidity":0.0,"battery":0.0},"origin":"receiver","protocol":"teknihall","uuid":"0000-98-3b-16-e96c5c","repeats":1}
2015.06.09 20:09:56.084 4: pilight(Parse): teknihall:0 not in white list
2015.06.09 20:10:00.005 4: pilight(Write): RCV (pilight_switch) -> SW_WZ_FS,on
2015.06.09 20:10:00.006 4: pilight(Write): {"action":"send","code":{"protocol":["intertechno_switch"],"id":15742938,"unit":0,"on":1}}
2015.06.09 20:10:00.007 5: pilight(SendNonBlocking): queue size 1
2015.06.09 20:10:00.026 5: pilight(Send): {"action":"send","code":{"protocol":["intertechno_switch"],"id":15742938,"unit":0,"on":1}}
2015.06.09 20:10:00.030 5: pilight(Send): RCV -> {"status":"success"}
2015.06.09 20:10:00.057 4: pilight(SendDone): message successfully send
2015.06.09 20:10:00.525 5: pilight(SendNonBlocking): queue size 0
2015.06.09 20:10:00.869 4: pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":15742938,"unit":0,"state":"on"},"repeat":1,"uuid":"0000-98-3b-16-e96c5c"}
2015.06.09 20:10:00.883 5: pilight dispatch PISWITCH,intertechno_switch,15742938,0,on
2015.06.09 20:10:00.884 4: pilight_switch_Parse: RCV -> PISWITCH,intertechno_switch,15742938,0,on
2015.06.09 20:10:04.980 4: pilight(Parse): RCV -> {"message":{"id":"F10","unit":61,"state":"off"},"origin":"receiver","protocol":"clarus_switch","uuid":"0000-98-3b-16-e96c5c","repeats":1}
2015.06.09 20:10:04.983 4: pilight(Parse): clarus_switch:F10 not in white list
2015.06.09 20:10:05.224 4: pilight(Parse): RCV -> {"message":{"id":0.0,"temperature":0.0,"humidity":0.0,"battery":0.0},"origin":"receiver","protocol":"teknihall","uuid":"0000-98-3b-16-e96c5c","repeats":1}
20
Der Versuch schlug auch fehl...
Nach FHEM-Neustart funktionierte dann aber wieder alles.
[/edith]
Zu sehen ist im Log leider nicht allzuviel, aber schau selbst.
Aufgetreten ist das Phänomen gestern Abend.
Grüße
anfichtn
Was genau ging denn nicht mehr, das schalten des [intertechno_switch"],"id":15742938,"unit":0?
Laut Log ging die Message zum daemon raus und wird mit success bestätigt und der neue Status wird auch an den Switch gesendet.
Das einzige, was wirklich seltsam ist, ist das State auf 0 steht. state oder STATE ??
Was sagt dann list <device-name des pilight_ctrl>?
Mal ein reset vom pilight_ctrl versucht?
Risiko
Zitat von: NeckCheck am 10 Juni 2015, 14:37:10
Ich habe jetzt mit folgenden Befehlen die Dose eingefügt in Fhem:
define Schreibtisch pilight elro_800_switch
Du verwendest nicht mein Modul. Hier geht es um pilight_ctrl und pilight_switch!!
Risiko
Moin!
Zitat von: Risiko am 10 Juni 2015, 21:17:40
Was genau ging denn nicht mehr, das schalten des [intertechno_switch"],"id":15742938,"unit":0?
Laut Log ging die Message zum daemon raus und wird mit success bestätigt und der neue Status wird auch an den Switch gesendet.
Ich hab nen LogAuszug unterschlagen, den gibts hier noch nachgereicht:
2015.06.09 15:29:31.607 4: pilight(Parse): RCV -> {"message":{"id":7,"unit":15,"state":"off"},"origin":"receiver","protocol":"arctech_switch_old","uuid":"0000-98-3b-16-e96c5c","repeats":1}
2015.06.09 15:29:31.610 4: pilight(Parse): intertechno_switch_old:7 not in white list
2015.06.09 15:29:46.911 4: pilight(Parse): RCV -> {"message":{"id":16,"unit":8,"state":"off"},"origin":"receiver","protocol":"arctech_switch_old","uuid":"0000-98-3b-16-e96c5c","repeats":1}
2015.06.09 15:29:46.914 4: pilight(Parse): intertechno_switch_old:16 not in white list
2015.06.09 15:30:00.017 4: pilight(Write): RCV (pilight_switch) -> SW_Liv_Radio,on
2015.06.09 15:30:00.018 4: pilight(Write): {"action":"send","code":{"protocol":["intertechno_switch"],"id":15742938,"unit":2,"on":1}}
2015.06.09 15:30:00.018 5: pilight(SendNonBlocking): queue size 1
2015.06.09 15:30:00.037 5: pilight(Send): {"action":"send","code":{"protocol":["intertechno_switch"],"id":15742938,"unit":2,"on":1}}
2015.06.09 15:30:00.040 5: pilight(Send): RCV -> {"status":"success"}
2015.06.09 15:30:00.063 4: pilight(SendDone): message successfully send
2015.06.09 15:30:00.527 5: pilight(SendNonBlocking): queue size 0
2015.06.09 15:30:00.889 4: pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":15742938,"unit":2,"state":"on"},"repeat":1,"uuid":"0000-98-3b-16-e96c5c"}
2015.06.09 15:30:00.898 5: pilight dispatch PISWITCH,intertechno_switch,15742938,2,on
2015.06.09 15:30:00.900 4: pilight_switch_Parse: RCV -> PISWITCH,intertechno_switch,15742938,2,on
2015.06.09 15:30:17.001 4: pilight(Parse): RCV -> {"message":{"id":0,"temperature":-67.77,"humidity":128.00,"battery":1,"channel":1},"origin":"receiver","protocol":"tfa","uuid":"0000-98-3b-16-e96c5c","repeats":1}
2015.06.09 15:30:17.008 4: pilight(Parse): tfa:0 not in white list
2015.06.09 15:30:31.300 4: pilight(Parse): RCV -> {"message":{"id":"F11","unit":63,"state":"off"},"origin":"receiver","protocol":"clarus_switch","uuid":"0000-98-3b-16-e96c5c","repeats":1}
2015.06.09 15:30:31.303 4: pilight(Parse): clarus_switch:F11 not in white list
dieser Schaltvorgang hat bereits nicht mehr funktioniert.
Zitat von: Risiko am 10 Juni 2015, 21:17:40
Das einzige, was wirklich seltsam ist, ist das State auf 0 steht. state oder STATE ??
Was sagt dann list <device-name des pilight_ctrl>?
Mal ein reset vom pilight_ctrl versucht?
Risiko
state. Verdammte Autokorrektur am Handy.
auf die Idee einen reset des pilight_ctrl bin ich auch gekommen, allerdings ohne sichtbaren Erfolg, state blieb stur bei "0".
Beim nächsten Auftreten des Fehlers mach ich nen list pilight_ctrl. daran hab ich gestern leider nicht gedacht.
Grüße
anfichtn
Zitat von: anfichtn am 10 Juni 2015, 21:34:48
Ich hab nen LogAuszug unterschlagen, den gibts hier noch nachgereicht:
dieser Schaltvorgang hat bereits nicht mehr funktioniert.
Da kann ich leider auch kein Fehlverhalten erkennen.
Kannst du bitte beim nächsten mal auch den verbose des switch auf 5 setzen.
Schaltet der state vom switch in FHEM auch nicht, oder nur die Hardware?
Zitat von: anfichtn am 10 Juni 2015, 21:34:48
state.
Sehr sehr seltsam. state wird im gesamten Modul nicht verwendet. Im Normalfall sollte es kein Reading state geben.
Risiko.
So, etwas zum lesen.
Internals:
API 6.0
DEF localhost:5000
DeviceName localhost:5000
FD 19
NAME pilight
NR 126
NTFY_ORDER 50-pilight
PARTIAL
RETRY_INTERVAL 60
STATE opened
TYPE pilight_ctrl
CHANGETIME:
Helper:
Dblog:
State:
Mydblog:
TIME 1433966333.92752
VALUE DISCONNECTED
Readings:
2015-06-10 21:58:21 rcv_raw 0
2015-06-10 22:31:23 state opened
Helper:
CON connected
LAST_RCV_PROTOCOL clarus_switch
LAST_RCV_RAW {"message":{"id":"F15","unit":63,"state":"off"},"origin":"receiver","protocol":"clarus_switch","uuid":"0000-98-3b-16-e96c5c","repeats":1}
sendQueue:
whiteList:
intertechno_switch:15742938
Attributes:
ContactAsSwitch 15742938
brands arctech:intertechno
ignoreProtocol *
room 99_System
verbose 5
Unter readings steht ein kleines state... derzeit mit "opened".
Wegen Verbose 5... ist jetzt auch bei alle 3 definierten Switches gesetzt.
Es schalten weder der state vom Switch noch die Hardware.
Ich helf dir gern wo ich nur kann.
Aber: das System muss funktionieren :) Ich bin irgendwie dagegen, dass kleine Kinder nachts fernsehen ^^
Grüße
anfichtn
Zitat von: Risiko am 10 Juni 2015, 21:20:03
Du verwendest nicht mein Modul. Hier geht es um pilight_ctrl und pilight_switch!!
Risiko
Ich habe nicht gemerkt dass es da mehrere Pilight Module gibt. Ich habe deins probiert, aber ich bekomme diese blöde Fehlermeldung " cannot load module ". Dann habe ich bisschen im Internet gesucht und das andere gefunden.
Eine Idee, was es mit der Fehlermeldung zu tun haben kann. Wie gesagt die ganzen Perl Pakete sind installiert.
Hallo anfichtn,
leider kann ich hier auch nicht viel erkennen.
rcv_raw ist 0, und das Reading state ist zeitlich neuer. Gab es einen Verbindungsabbruch zum daemon?
Könntest du mal das device aus DB_Log raus nehmen?
Zitat von: anfichtn am 10 Juni 2015, 22:37:26
Wegen Verbose 5... ist jetzt auch bei alle 3 definierten Switches gesetzt.
Hast du hier auch noch Logs?
Risiko
Zitat von: NeckCheck am 11 Juni 2015, 13:04:24
Eine Idee, was es mit der Fehlermeldung zu tun haben kann. Wie gesagt die ganzen Perl Pakete sind installiert.
Nein habe ich nicht. Ich denke immer noch, dass da was fehlt.
Du kannst ja auch keine weiteren Infos liefern.
Risiko
Zitat von: Risiko am 11 Juni 2015, 20:44:22
Hallo anfichtn,
leider kann ich hier auch nicht viel erkennen.
rcv_raw ist 0, und das Reading state ist zeitlich neuer. Gab es einen Verbindungsabbruch zum daemon?
Könntest du mal das device aus DB_Log raus nehmen?
Hast du hier auch noch Logs?
Risiko
Derzeit nicht.
Liefere ich aber beim nächsten auftreten.
Grüße
anfichtn
Ich hatte nun auch wieder das Problem, dass ich den FHEM-Service neu starten musste.
Im State des CTRL-Device stand im State auch "0". Nach dem Reset ging dieser auf "Open". Aber dennoch wurden keine Geräte eingeschaltet. Die GUI reagierte nun aber.
Sieht auch für mich danach aus, als wäre die Verbundung zum Pilight-Daemon verloren gegangen.
Hallo.
Habe heut nochmal alles nachgesehen. state wird im Modul selbst nicht verwendet. Allein DevIo setzt ihn auf open oder disconnected. Keine Ahnung wo die 0 herkommen soll. Verwendest du auch Dblog?
Wenn die Verbindung zum daemon verloren geht, sollte das auch im Log zu sehen sein
Komme da leider nicht weiter, da ich den Fehler nicht habe und alle bisherigen Logs ok waren.
Risiko
Ich hab jetzt mal ein Log für das CTRL-Device angelegt und werde es mal beobachten. Im globalen FHEM-Log konnte ich auf die Schnelle (mittels Smartphone) nichts finden.
Ich nutze übrigens kein DbLog.
Inwiefern könnte ich dir helfen?
Eigenes Log, sehr gut.
Es wäre wichtig, wenn man irgend wie mit bekommt, wann es passiert.
State mit 0 ist aktuell der einzige Anhaltspunkt. Könnte ne Version mit speziellen Logs zur Verfügung stellen, wo der state überwacht wird.
Risiko
Klaro. Her damit. :-)
Ich hab schon "verbose" auf "5".
Ich helfe auch gerne.
Btw: hast du den Empfänger über den Bandpass - AtTiny laufen? Wenn ja, an 5V oder an 3,3V angeschlossenen?
Grüße
@anfichtn: Falls du mich meinst: ich habe keinen Empfänger angeschlossen.
Nachtrag
Kleines Update. Ich stelle gerade fest, dass im pi_ctrl-Device wieder der Status "0" steht.
Im dazugehörigen Log finde ich jedoch absolut gar nichts. Trotz "vebose:5".
Ist aber, glaube ich, auch total egal.
Und zwar war die Statusänderung zu einem Zeitpunkt, wo FHEM neu gestartet wurde. Beim Neustart von FHEM wird also höchstwahrscheinlich dieser Status gesetzt.
Aber auch das ist scheinbar egal:
Denn meine pi_switche laufen wunderbar. Egal wie der Status von pi_ctrl aussieht, ich kann die Zwischenstecker problemlos schalten.
Ich denke somit, dass wir in der falschen Richtung suchen.
---
Nichtsdestotrotz kann ich natürlich gerne ein Debug-Log anlegen. Denn irgendetwas führt halt sporadisch dazu, dass das Fhem-Pilight-Modul die (vermutlich) Verbindung zum pilight-daemon verliert und nur ein Neustart des Fhem-Services weiterhilft.
Könnten das evtl. durchgeführte Updates oder Neustarts (shutdown restart) sein?
Zitat von: anfichtn am 17 Juni 2015, 23:33:59
Btw: hast du den Empfänger über den Bandpass - AtTiny laufen? Wenn ja, an 5V oder an 3,3V angeschlossenen?
Ja. An 5V
Danke. Ich hab das dann mal ebenso gemacht. Bisher läuft es. Deutlich weniger CPU-Last Kann ich zwar nicht feststellen, aber okay.
Zitat von: Funk.Odyssey am 18 Juni 2015, 08:11:27
Kleines Update. Ich stelle gerade fest, dass im pi_ctrl-Device wieder der Status "0" steht.
Im dazugehörigen Log finde ich jedoch absolut gar nichts. Trotz "vebose:5".
Ist aber, glaube ich, auch total egal.
Und zwar war die Statusänderung zu einem Zeitpunkt, wo FHEM neu gestartet wurde. Beim Neustart von FHEM wird also höchstwahrscheinlich dieser Status gesetzt.
Nicht ganz. Ich lösche eigentlich explizit das Reading state im CTRL-Device, da nur das interne STATE benötigt wird.
Zitat von: Funk.Odyssey am 18 Juni 2015, 08:11:27
Aber auch das ist scheinbar egal:
Denn meine pi_switche laufen wunderbar. Egal wie der Status von pi_ctrl aussieht, ich kann die Zwischenstecker problemlos schalten.
Wie gesagt, state sollte es nicht geben. Wenn aber das interne STATE auf disconnected steht, dann ist die Verbindung zum daemon unterbrochen.
Zitat von: Funk.Odyssey am 18 Juni 2015, 08:11:27
Ich denke somit, dass wir in der falschen Richtung suchen.
Könnte sein. Würde es aber noch nicht ausschließen wollen.
Zitat von: Funk.Odyssey am 18 Juni 2015, 08:11:27
Könnten das evtl. durchgeführte Updates oder Neustarts (shutdown restart) sein?
Damit habe ich auch noch nie Probleme gehabt.
Ich versuche am WE eine neue Version mit mehr Log's zu erstellen und hoffentlich finde ich dann den Fehler.
Risiko
Eine Lösung für mein Protokoll-Problem scheint jedoch nicht in Sicht, aber vllt hat ja jemand eine Idee, wie man den Datenverkehr zwischen Technoline Wetterstation mit Aussensender TX9... Und Mebus Wetterstation mit scheinbar ähnlichem Aussensender mitlesen kann.
Jede Wetterstation empfängt übrigens den Sender der anderen Station problemlos mit.
Grüße
anfichtn
Zitat von: anfichtn am 18 Juni 2015, 20:03:39
Danke. Ich hab das dann mal ebenso gemacht. Bisher läuft es. Deutlich weniger CPU-Last Kann ich zwar nicht feststellen, aber okay.
Bei mir ist es von ca 50% auf unter 1% gesunken. Sieht man super in pilight-web
Risiko
Ich hatte vorher auch "nur" etwa 3%, und bin jetzt bei 0,4...
Zitat von: Risiko am 04 Juni 2015, 16:09:02
Kenne ich nicht. Habe das System mit pilight seit mehreren Monaten im Dauereinsatz.
Wie hast du das festgestellt?
Ohne weitere Infos kann ich da leider auch nicht helfen.
Bei mir stürzt immer wieder aus unerklärlichen Gründen FHEM ab. Neustarten von FHEM bringt nichts, erst ein Reboot hilft.
Pilight ist ohne Anpassungen (ausser den Port habe ich eingefügt) für die FHEM-Verbindung.
Gibt es irgendeine gute Loggingmöglichkeit?
Allgemeiner Wunsch: Wäre es möglich ein disable einzubauen, dass man pilight_ctrl deaktivieren kann? Ich teste derzeit ob die Kombination pilight + fhem das Problem ist, oder ob Pilight alleine schon der Verursacher ist.
Gruss und danke
Zitat von: Hauswart am 19 Juni 2015, 09:58:18
Allgemeiner Wunsch: Wäre es möglich ein disable einzubauen, dass man pilight_ctrl deaktivieren kann?
Mit set <device> disconnect kann man nun die Verbindung manuell zum daemon beenden. Es wird jetzt auch nicht mehr alle 60s neu versucht eine Verbindung aufzubauen.
Das device macht nichts mehr.
Weiterhin habe ich eine Überwachung für das Reading state eingebaut. Erhoffe mir dadurch, den gemeldeten Fehlern auf die Spur zu kommen.
Das Ganze ab morgen per update.
Risiko.
Super danke. Mein Stand derzeit Pilight ist deaktiviert und FHEM stürzt nicht mehr ab... Jetzt mal schauen ob FHEM und Pilight laufen können ohne Integration.
Moin,
Ich lese schon eine Weile mit und muss erstmal sagen danke für dieses super Forum.
Nachdem ich es zeitlich endlich geschafft habe Antennen an meine Sender/Empfänger zu löten brennt mir doch noch ein Problem unter den Nägeln.
Mein pilight_ctrl steht immer auf disconnected. Der Pilight-Daemon ist aber da, auf jeden Fall spuckt er keine Fehler aus. Auch das direkte ansprechen über das Terminal funktioniert. Ich will nur nicht für jede Steckdose ein Notify einrichten, damit ich sie ansprechen kann und Empfangen wäre auch nett ;)
Mache ich irgend etwas falsch? Ich habe es wie folgt Definiert:
define Fernbedienung pilight_ctrl 192.168.2.23:5000
Das ist ein Auszug aus dem Log dazu:
2015.06.20 19:30:39 3: Opening Fernbedienung device 192.168.2.23:5000
2015.06.20 19:30:39 3: Can't connect to 192.168.2.23:5000: Connection refused
2015.06.20 19:30:40 2: Fernbedienung(Check): Could not connect to pilight-daemon 192.168.2.23:5000
Ach so, FHEM und Pilight laufen bei mir auf einem Pi 2 und sind auf dem neusten stand.
Danke im Voraus.
In deiner pilight - config fehlt der Eintrag "port": 5000
Grüße
anfichtn
Danke,
Du hattest vollkommen recht. Der Fehler war das der Port nicht eingetragen war. Ich habe den gefühlt schon hundert mal eingetragen. Aber auf den Gedanken Pilight dabei zu stoppen bin ich nicht gekommen. Denn er scheint dann die config mit den geladenen Daten wieder zu überschreiben. Also ohne Port Eintrag ;)
@Risiko:
Eben shutdown restart gemacht, und danach folgendes gefunden:
(http://images.tapatalk-cdn.com/15/06/22/2d337e9ff877b1e7fb9ec75c961cb8fc.jpg)
Grüße
anfichtn
Ps: ich würde gern pilight-firmware per default zur whitelist hinzugefügt haben... Im Log ist die Meldung die derzeit einzige, aber extrem nervig :-(
Was willst du denn mit pilight firmware anfangen?
Allein in der white list nutzt es nichts
Ich habe die Einträge im Log alle 30min.
Ich denke, dass es durch folgendes AT (für Watchdog) ausgelöst wird:
define at_FHEM.save at +*00:30:00 {WriteStatefile}
Die Frage ist nur, ob uns das nun weiterhilft.
Zitat von: Funk.Odyssey am 22 Juni 2015, 23:03:41
Ich habe die Einträge im Log alle 30min.
Ich denke, dass es durch folgendes AT (für Watchdog) ausgelöst wird:
define at_FHEM.save at +*00:30:00 {WriteStatefile}
Die Frage ist nur, ob uns das nun weiterhilft.
Der Befehl sorgt bei mir auch für Log-Einträge / Fehler - habe auch noch keine Lösung... aber worauf bezog sich dein Post? :o
Zitat von: Funk.Odyssey am 22 Juni 2015, 23:03:41
Ich denke, dass es durch folgendes AT (für Watchdog) ausgelöst wird:
define at_FHEM.save at +*00:30:00 {WriteStatefile}
Die Frage ist nur, ob uns das nun weiterhilft.
Also WriteStatefile hat die readings auf 0 gesetzt, weil die readings noch bekannt waren aber keinen gültigen Wert hatten.
Die Readings werden aus fhem.save restauriert. Das Löschen zu diesem Zeitpunkt (StateFn) funktioniert leider nicht. Ich wollte damit verhindern, dass state einfach auf den letzten Wert gesetzt wird, obwohl keine Verbindung zum pilight-daemon besteht.
Ab jetzt\morgen enthalten die readings state und rcv_raw immer einen Wert. Damit ist das 0 Problem gelöst und ich\wir können vermutlich mit der Suche des eigentlichen Fehlers von vorn beginnen. >:(
Risiko
Habt ihr den AtTiny eigentlich selbst geflasht oder bestellt?
Hallo,
nun war ich wieder vom Problem betroffen.
Zwei Pilight-Zwischenstecker waren bereits weit früher (ca. 14:00 Uhr) eingeschaltet.
Dann wollte ich um ca. 19:12 Uhr weitere Zwischenstecker (pi_switch) einschalten. Leider ohne Erfolg.
Daraufhin hatte ich ein Reset bei "pi_ctrl" durchgeführt: Ohne Erfolg.
Dann habe ich ganz normal über Fhem ein "shutdown restart" durchgeführt: Dann lief es wieder.
Filelog: pi_ctrl
2015-06-23_14:04:03 pi_ctrl rcv_raw: {"origin":"sender","protocol":"pollin","message":{"systemcode":6,"unitcode":2,"state":"on"},"repeat":1,"uuid":"0000-b8-27-eb-c8360d"}
2015-06-23_19:12:35 pi_ctrl rcv_raw: {"origin":"sender","protocol":"pollin","message":{"systemcode":6,"unitcode":3,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-c8360d"}
2015-06-23_19:15:39 pi_ctrl reset
2015-06-23_19:16:00 pi_ctrl rcv_raw: {"origin":"sender","protocol":"pollin","message":{"systemcode":6,"unitcode":8,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-c8360d"}
2015-06-23_19:17:41 pi_ctrl rcv_raw: {"origin":"sender","protocol":"pollin","message":{"systemcode":6,"unitcode":4,"state":"on"},"repeat":1,"uuid":"0000-b8-27-eb-c8360d"}
2015-06-23_19:17:44 pi_ctrl rcv_raw: {"origin":"sender","protocol":"pollin","message":{"systemcode":6,"unitcode":1,"state":"on"},"repeat":1,"uuid":"0000-b8-27-eb-c8360d"}
Fhem-Log siehe Anhang
Selber flashen. Ist ganz einfach und unkompliziert.
Grüße
anfichtn
Zitat von: anfichtn am 23 Juni 2015, 20:58:34
Selber flashen. Ist ganz einfach und unkompliziert.
Super, dann muss ich mal nen Teil bestellen und den Programmer abstauben :)
der Pilight Deamon bremst ja schon ganz schön....
Zitat von: Funk.Odyssey am 23 Juni 2015, 20:14:11
Hallo,
nun war ich wieder vom Problem betroffen.
Zwei Pilight-Zwischenstecker waren bereits weit früher (ca. 14:00 Uhr) eingeschaltet.
Dann wollte ich um ca. 19:12 Uhr weitere Zwischenstecker (pi_switch) einschalten. Leider ohne Erfolg.
Daraufhin hatte ich ein Reset bei "pi_ctrl" durchgeführt: Ohne Erfolg.
Dann habe ich ganz normal über Fhem ein "shutdown restart" durchgeführt: Dann lief es wieder.
Danke. Damit kann ich was anfangen.
Die Messages gehen nicht mehr raus und die Sendequeue müllt sich voll. Warum, weiß ich noch nicht.
Auf jeden Fall muss beim reset ein löschen der Queue rein.
Nachtrag: Löschen der Queue soeben gefixt.
Weiterhin habe ich das Timeout für den Abbruch eines Sendebefehls von 4s auf 1s reduziert. Die Timeout-Zeit kann über das Attribut SendTimeout verändert werden.
Risiko.
Zitat von: klausw am 23 Juni 2015, 21:08:20
Super, dann muss ich mal nen Teil bestellen und den Programmer abstauben :)
der Pilight Deamon bremst ja schon ganz schön....
Du brauchst keinen Programmer. AtTiny entsprechend anklemmen, pilight-firmware installieren und mit pilight-flash die Firmware auf den AtTiny beamen.
Ready and go.
Grüße
anfichtn
Zitat von: anfichtn am 23 Juni 2015, 22:20:54
Du brauchst keinen Programmer. AtTiny entsprechend anklemmen, pilight-firmware installieren und mit pilight-flash die Firmware auf den AtTiny beamen.
Ready and go.
Grüße
anfichtn
Oh, noch besser.
thx
Hallo Zusammen,
also ich habe jetzt pilight version 7 zusammen mit einem Arduino Nano USB an meinem Raspberry am laufen (Empfänger und Sender über den Arduino).
Das läuft mit den Modulen pilight_ctrl, pilight_switch, pilight_temp hier unter FHEM inzwischen ganz hervorragend.
Ich habe mein "altes pilight" + Ansteuerung über GPIOs vom Raspi dadurch ersetzt.
Das ist echt ein super modul! Danke an den/die Programmierer!
In Verbindung mit den Empfängern/Sendern und der Kombination Raspberry ist mir folgendes aufgefallen:
Eine gute + stabile Spannungsversorgung ist für den Raspberry unerlässlich!
Einige günstige 1A Netzteile sind hier bei mir mit den merkwürdigsten Fehlern an den Sender/Empfängern aufgefallen. (unerklärliche Reboots des Raspi, Empfänger empfängt plötzlich nichts mehr, oder der Sender geht nicht mehr).
Sollte also jemand Probleme solcher Art haben, vielleicht mal das Netzteil ersetzen.
Für pilight_ctrl würde ich mir in den Readings noch ein "aufdröseln" der Raw Daten wünschen ;-).
Ich würde gern über eine günstige Fernbedienung noch die Homematic Rollladen steuern.
Über DOIF in etwa: Leider bekomme ich es nicht hin das über die rcv_raw vernünftig zu basteln... Einfach weil ich wohl mit regex etc nicht so klar komme und ich nicht weiß wie ich das aus den rcv_raw aufröseln soll....
Ich stelle mir das in etwa so vor:
define ROLLO_HOCH DOIF ([myctrl:rcv_raw] = PROTOCOL:elro_800_switch,UNITCODE:19,SYSTEMCODE:4) (set ROLLO_WZ_1 auf)
Gruß
Jens
Zitat von: Jens_B am 25 Juni 2015, 08:11:05
Hallo Zusammen,
also ich habe jetzt pilight version 7 zusammen mit einem Arduino Nano USB an meinem Raspberry am laufen (Empfänger und Sender über den Arduino).
Das läuft mit den Modulen pilight_ctrl, pilight_switch, pilight_temp hier unter FHEM inzwischen ganz hervorragend.
Ich habe mein "altes pilight" + Ansteuerung über GPIOs vom Raspi dadurch ersetzt.
Darf man Fragen, welche Vorteile dadurch entstanden sind?
Zitat von: Jens_B am 25 Juni 2015, 08:11:05
In Verbindung mit den Empfängern/Sendern und der Kombination Raspberry ist mir folgendes aufgefallen:
Eine gute + stabile Spannungsversorgung ist für den Raspberry unerlässlich!
Einige günstige 1A Netzteile sind hier bei mir mit den merkwürdigsten Fehlern an den Sender/Empfängern aufgefallen. (unerklärliche Reboots des Raspi, Empfänger empfängt plötzlich nichts mehr, oder der Sender geht nicht mehr).
Sollte also jemand Probleme solcher Art haben, vielleicht mal das Netzteil ersetzen.
Mmh ich habe sehr merkwürdige FHEM-Abstürze (keine Reboots, wobei FHEM erst nach einem Reboot wieder läuft - ein Neustart des Services hilft nicht) die ich mir nicht erklären kann. Hattest du die Probleme auch ohne Einsatz von Risiko seinem Modul?
Scheinbar (teste erst seit zwei Tagen) stürzt bei mir FHEM nur ab, wenn ich das Modul hier verwende. Läuft FHEM und Pilight getrennt von einander auf meinem Raspberry (Sender+Empfänger via GPIO) läuft es problemlos. Muss aber noch weiter testen. Ich verwende als Stromversorgung des Raspberry ein aktiver USB-Hub. An diesem USB-Hub habe ich ein Micro USB-Kabel angeschlossen, welcher den Raspberry versorgt.
ZitatDarf man Fragen, welche Vorteile dadurch entstanden sind?
durch das auslagern auf den Arduino ist die CPU Last am Raspi gesunken. Außerdem sieht das ganze auch schöner aus jetzt ;-)
ZitatScheinbar (teste erst seit zwei Tagen) stürzt bei mir FHEM nur ab, wenn ich das Modul hier verwende. Läuft FHEM und Pilight getrennt von einander auf meinem Raspberry (Sender+Empfänger via GPIO) läuft es problemlos. Muss aber noch weiter testen. Ich verwende als Stromversorgung des Raspberry ein aktiver USB-Hub. An diesem USB-Hub habe ich ein Micro USB-Kabel angeschlossen, welcher den Raspberry versorgt.
Also über nen Aktiven Hub würde ich das Ganze nicht betreiben, denn auch der HUB bietet an USB max 500mA. Es sei denn der Hub bietet einen sog. Ladeport. Sowas hier:
http://www.amazon.de/Inateck-1-Ladeport-Tabletrechnern-Smartphone-Netzadapter/dp/B00GT8QW4U/ref=sr_1_7?ie=UTF8&qid=1435221609&sr=8-7&keywords=usb+mit+ladeport
Dort stehen dann an dem speziellen Ladeports bis 2A zu Verfügung.
Meine Empfehlung, wenn man dan den USB Ports des Raspi noch anderes Sachen hat, oder eben der Raps unmotiviert abstürzt:
Seperates GUTES Netzteil nutzen.
Das Netzteil ist meiner Meinung nach entscheidend.
Ich empfehle in dem Zusammenhang mal folgende Webseite
http://www.elektronik-kompendium.de/sites/raspberry-pi/1912111.htm
Gruß
Jens
@Jens_B
Danke für deine ausführlichen Informationen. Könnte evtl. einigen helfen.
Zitat von: Jens_B am 25 Juni 2015, 10:43:53
durch das auslagern auf den Arduino ist die CPU Last am Raspi gesunken. Außerdem sieht das ganze auch schöner aus jetzt ;-)
Ok. 1. bekommt man mit nem Attiny hin und 2. ist Geschmackssache ;)
Zitat von: Jens_B am 25 Juni 2015, 08:11:05
Für pilight_ctrl würde ich mir in den Readings noch ein "aufdröseln" der Raw Daten wünschen ;-).
Ich würde gern über eine günstige Fernbedienung noch die Homematic Rollladen steuern.
Über DOIF in etwa: Leider bekomme ich es nicht hin das über die rcv_raw vernünftig zu basteln... Einfach weil ich wohl mit regex etc nicht so klar komme und ich nicht weiß wie ich das aus den rcv_raw aufröseln soll....
Ich stelle mir das in etwa so vor:
define ROLLO_HOCH DOIF ([myctrl:rcv_raw] = PROTOCOL:elro_800_switch,UNITCODE:19,SYSTEMCODE:4) (set ROLLO_WZ_1 auf)
Werde über den Einbau weiterer Readings nachdenken.
Aktuell sehe ich hier zwei Möglichkeiten:
1. du definierts noch einen Switch mit dem elro_800 Protokoll und reagierst auf state
2. du bastelst eine Hilfsfunktion die per notify aufgerufen wird wenn eine neue Meldung rein kommt. In dieser kannst du dann den json-string ganz einfach auswerten (siehe auch mal hier: http://forum.fhem.de/index.php/topic,38463.15.html)
Risiko
Hallo Risiko,
ja, das mit dem zusätzlichen Switch als "dummy" habe ich mir schon so gedacht. Allerdings muß ich mir auch noch eine Lösung dafür einfallen lassen, da die Rollladen ja auch über Zeitsteuerung per hem laufen, das sich das nicht in die Quere kommt ;-)...
Was hast Du da alles an deinem Raspberry dran? Links der Stick ist was für eine Antenne? und rechts? Das ist die für Pilight?
Mein Arduino Modul ist "offen" ;-)
Was ist ein Attiny?
Gruß
Jens
Zitat von: Jens_B am 25 Juni 2015, 21:30:45
Was hast Du da alles an deinem Raspberry dran? Links der Stick ist was für eine Antenne? und rechts? Das ist die für Pilight?
Links: cul 868Mhz und usb stick
Rechts: 433 Mhz Antenne Sender, Empfänger und Attiny45+Widerstände sind im Pi-Gehäuse und an GPIO angeschlossen
Zitat von: Jens_B am 25 Juni 2015, 21:30:45
Was ist ein Attiny?
https://github.com/pilight/pilight_firmware
https://klein-gedruckt.de/2015/05/steckdosen-fernsteuern-mit-pilight-teil-1
Muss denn die SPI immer am Attiny angeschlossen sein?
Ich dachte, die ist nur zum Programmieren.
Zitat von: Risiko am 25 Juni 2015, 22:38:18
Links: cul 868Mhz und usb stick
Rechts: 433 Mhz Antenne Sender, Empfänger und Attiny45+Widerstände sind im Pi-Gehäuse und an GPIO angeschlossen
https://github.com/pilight/pilight_firmware
https://klein-gedruckt.de/2015/05/steckdosen-fernsteuern-mit-pilight-teil-1
Ahja, die Antenne ist also nur für den Sender? Die Antenne für den Empfänger ist bei Dir im Raspberry? Und das funktioniert?
Für meine Homematic Sachen benutze ich den alten runden HMLAN Adapter.
Ich hab im Augenblick noch einen CC1101 433mhz liegen und einen Arduino, da überlege ich noch ob es Sinn macht daraus etwas zu bauen.
Gruß
Jens
Zitat von: klausw am 25 Juni 2015, 23:25:03
Muss denn die SPI immer am Attiny angeschlossen sein?
Ich dachte, die ist nur zum Programmieren.
Laut Doku ist das auch so. Habe auch die volle Verdrahtung permanent.
Zitat von: Jens_B am 26 Juni 2015, 07:12:28
Ahja, die Antenne ist also nur für den Sender? Die Antenne für den Empfänger ist bei Dir im Raspberry? Und das funktioniert?
Nein. Die Antenne ist für Sender und Empfänger.
Hallo,
Cannot load module pilight_ctrl...
Mein fhem läuft auf einem Raspi ..25 und pilight 7.0 läuft auf einem Raspi ..64 im Netzwerk.
Nachdem ich ein Update für fhem vornahm, versuchte ich mich an der Kopplung beider.
define myctrl pilight_ctrl 192.x.x.64:5001 7.0
fhem antwortete:
Cannot load module pilight_ctrl
Hab ich was übersehen? Muss auf dem fhem-Raspi noch was installiert werden?
Danke!
Hallo,
habe auch aktuelles FHEM und pilight 7.0. Läuft alles lokal auf einem Raspi.
Bekomme beim Eingeben von
define myctrl pilight_ctrl 192.x.x.x:5000
auch die Antwort: "Cannot load module pilight_ctrl"
Dabei liegt im FHEM-Verzeichnis die Datei "10_pilight_ctrl.pm".
In fhem.log kommt:
2015.06.28 00:22:10 1: reload: Error:Modul 10_pilight_ctrl deactivated:
Can't locate JSON.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr
/local/lib/site_perl . ./FHEM ./FHEM/lib) at ./FHEM/10_pilight_ctrl.pm line 42.
BEGIN failed--compilation aborted at ./FHEM/10_pilight_ctrl.pm line 42.
Deshalb habe ich es mit
define Tischlicht pilight rsl366 1 1
attr Tischlicht remote_ip 192.x.x.x
attr Tischlicht remote_port 5000
versucht. Beim Schalten steht dann im fhem.log
2015.06.28 00:18:22 3: pilight command: on
2015.06.28 00:18:22 3: pilight: ERROR. No handshake with pilight-daemon. Received: >>><<<
In /etc/pilight/config.json habe ich in der Sektion "Settings"
"port": 5000
für den pilight-daemon eingegeben.
Was mir momentan nicht klar ist:
Kann man sowohl mit dem Modul "pilight" als auch mit den Modulen "pilight_ctrl", "pilight_switch" ... Kontakt mit dem pilight-deamon aufnehmen oder schließt das eine das andere aus? :o
Installiere mal folgendes:
sudo apt-get update && sudo apt-get install libjson-perl -y
Zitat von: Risiko am 26 Juni 2015, 22:31:21
Nein. Die Antenne ist für Sender und Empfänger.
Hast Du Empfänger und Sender über die Antenne quasi als Y verbunden?
libjson-perl hat tatsächlich gefehlt. Nun unterhält sich fhem und der pilight-deamon bestens.
Danke! :D
Zitat von: Hauswart am 28 Juni 2015, 01:34:03
Installiere mal folgendes:
sudo apt-get update && sudo apt-get install libjson-perl -y
Das hat funktioniert. Zuerst updatete ich den pilight-raspi, ohne Wirkung - dann den fhem-raspi, sofort war myctrl definiert.
Danach definierte ich eine Temperaturmessung, die bereits unter pilight läuft.
define myctrl pilight_temp ds18b20 000001f03652
Ich möge zuerst myctrl löschen, da es schon definiert sei. OK
Lässt sich definieren.. erscheint auch in unsorted als myctrl.. angeklickt - Fenster zeigt die Definition aber keine Temperatur oder eine get Option.
Offensichtlich habe ich den Sinn der Anwendung nicht durchschaut. Gibt es Anwendungsbeispiele? Sowas ist immer sehr anschaulich.
Danke und Grüße
Zitat von: Vorhand am 28 Juni 2015, 10:25:08
define myctrl pilight_temp ds18b20 000001f03652
Die Verbindung zwischen pilight und fhem hast Du ja schon mit
myctrl benannt.
Für den ds18b20 must Du Dir einen neuen Namen ausdenken, z.B.
AussenTemp dann funktioniert's.
Bin ich auch zunächst drüber gestolpert, da es so im Beispiel in der Commandref steht.
Wenn Du Dir in deinem fhem den link
myctrl anschaust, solltest Du in den Readings deine Sensoren sehen (ähnlich wie in pilight-receive).
...stehe auf irgendeinem Schlauch!
Kannst du anhand eines Stück Beispiel-Codes mal aufzeigen, was konkret in fhem eingegeben werden sollte.
In pilight muss wegen dieses fhem-Zugriffs wohl nicht geändert werden!?
Übrigens:
Wenn ich eingebe: define myctrl pilight_ctrl 192.168.x.x:5001 7.0
dann erscheint sofort ein Fenster mit diesem device. Der Status ist allerdings "disconnected" und mit set "reset" lässt er sich nicht ändern!?
Mein Ziel ist die Ansteuerung von 433ger Steckdosen aus fhem! Nebenbei nehme ich natürlich auch die 1wire Sensoren mit, die rel. einfach an diesem Raspi hängen.
Grüße
Zitat von: Vorhand am 29 Juni 2015, 09:40:24
Mein Ziel ist die Ansteuerung von 433ger Steckdosen aus fhem! Nebenbei nehme ich natürlich auch die 1wire Sensoren mit, die rel. einfach an diesem Raspi hängen.
Grüße
Also direkt am Raspberry angeschlossene DS18B20 werte ich mit dem Modul 58_GPIO4.pm aus. :)
# Activating GPIO-Ports on Raspberry Pi
# http://www.fhemwiki.de/wiki/Raspberry_Pi_und_1-Wire#ab_2015_bzw._Kernelversion_3.18.3
sudo echo "# activating 1-wire with pullup" >> /boot/config.txt
sudo echo "dtoverlay=w1-gpio-pullup" >> /boot/config.txt
# Copying FHEM modules
sudo cp /opt/fhem/contrib/58_GPIO4.pm /opt/fhem/FHEM/58_GPIO4.pm(den passenden define für das Modul habe ich gerade nicht im Kopf, schaue es in der Device Doku schnell nach)
Habe ich bei mir im Pilight Install drinnen, da ich Pilight und DS18B20 Sensoren beide an den GPIO-Ports dran habe: https://github.com/Kolbi/FHEM/blob/master/pilight_install.sh
Danke für die Antwort. Ist schon klar, dass es auch ohne pilight geht.
Ich dachte die Module sind für die Kopplung zu einem reinen pilight-server gedacht - mit allem, was daran angeschlossen ist und mittels pilight bereits läuft.
Gibt es denn eine fhem-Anwendung, in der diese Kopplung genutzt wird - z.B. schalten von 433er Funksteckdosen?
Gibt es Dokumentation zu den fhem-Programmen 10_pilight_ctrl.pm über die Commandref hinaus?
Danke.
Zitat von: Vorhand am 29 Juni 2015, 09:40:24
Übrigens:
Wenn ich eingebe: define myctrl pilight_ctrl 192.168.x.x:5001 7.0
dann erscheint sofort ein Fenster mit diesem device. Der Status ist allerdings "disconnected" und mit set "reset" lässt er sich nicht ändern!?
Der Port ist der falsche. Statt 5001 musst Du 5000 eingeben.
Hast Du in deinem "settings"-Block in /etc/piliert/config.json zusätzlich zum
"webserver-http-port": 5001 den pilight-deamon-port mit
"port": 5000 eingestellt?
Zitat von: Vorhand am 29 Juni 2015, 19:01:24
Ich dachte die Module sind für die Kopplung zu einem reinen pilight-server gedacht - mit allem, was daran angeschlossen ist und mittels pilight bereits läuft.
So sollte es sein.
Zitat von: Vorhand am 29 Juni 2015, 19:01:24
Gibt es denn eine fhem-Anwendung, in der diese Kopplung genutzt wird - z.B. schalten von 433er Funksteckdosen?
Gibt es Dokumentation zu den fhem-Programmen 10_pilight_ctrl.pm über die Commandref hinaus?
Denke, dass jetzt schon einige die Module nutzen. Auch beispielsweise zum Schalten von Steckdosen
Außer der Commandref gibt es aktuell aufgrund Zeitmangels von mir keine weitere Doku.
Was ist aber aus der Commandref nicht zu verstehen? Beispiele sind da ja auch drin.
Alle bisherigen Probleme und Fragen wurden bereits in diesem Thread beantwortet.
Für weitere Hilfe, müsstest du dann etwas ausführlicher werden. Aber erstmal viel Erfolg.
Risiko
Zitat von: AitschPi am 28 Juni 2015, 04:02:26
Hast Du Empfänger und Sender über die Antenne quasi als Y verbunden?
Joh.
Zitat von: Risiko am 29 Juni 2015, 22:46:53
Joh.
Danke, werde dann mal die Planung korrigieren und die Zahl der Antennen reduzieren... ;o)
Ui, das ist aber mutig die Sender und Empfänger quasi direkt ohne entkoppeln zu verbinden ...
Das könnte auf Dauer der Empfänger nicht mögen....
Gesendet von meinem iPhone mit Tapatalk
Ja, so hatte ich das auch im Hinterkopf.
Gesendet von iPhone mit Tapatalk - Tippfehler sind gratis.
Hallo Risiko,
habe zwei raspis mit über GPIO angeschlossene DHT22-Sensoren und FHEM- und pilight-Installation. Beide DHT22-Sensoren sind jeweils an den raspis am selben GPIO angeschlossen.
Wird jetzt in FHEM ein device pilight_temp mit ID GPIO definiert, sammelt dieses sämtliche Messwerte der beiden DHT22-Sensoren ein, da sich die pilight-Instanzen automatisch (ohne mein Zutun) miteinander verbunden haben.
Bug oder Feature? Auf die in config.json Gerätenamen (Sektion "devices") kann ich ja mit pilight_temp nicht zugreifen, oder?
Gruß,
thymjan
Edit:
Habe jetzt eine pilight Instanz als standalone definiert (in config.json bei "settings": "standalone": 1) jetzt ist der Spuk vorbei...
Noch ein Nachtrag:
Bei einem von pilight abgefragten DHT22 Sensor wird das Aktualisierungsinterval des in FHEM übernommenen Sensors durch die pilight config.json Datei bestimmt, oder? D.h. eigentlich muss ich die mit pilight_temp definierten Sensoren nicht in config.json auflisten, für das Polling-Intervall dann aber trotzdem (bei Sensoren die nicht selber funken).
@Risiko: Könntest du bitte mal einen Blick auf folgenden Random-Timer Thread (http://forum.fhem.de/index.php/topic,14010.msg309471.html#msg309471) werfen? Da haben einige Leute (wie auch ich) Fehler im FHEM-Log und es könnte eventuell mit deinem Modul zu tun haben. Vielleicht hast du ja eine Idee. Danke vielmals.
Zitat von: thymjan am 04 Juli 2015, 15:17:00
Bug oder Feature? Auf die in config.json Gerätenamen (Sektion "devices") kann ich ja mit pilight_temp nicht zugreifen, oder?
Nein, dass ist auch nicht notwendig.
Zitat von: thymjan am 04 Juli 2015, 15:17:00
Habe jetzt eine pilight Instanz als standalone definiert (in config.json bei "settings": "standalone": 1) jetzt ist der Spuk vorbei...
Das sich zwei pilight-instanzen automatisch verbinden, ist mir auch neu.
Vielen Dank für deine Erläuterungen.
Zitat von: thymjan am 04 Juli 2015, 15:17:00
Bei einem von pilight abgefragten DHT22 Sensor wird das Aktualisierungsinterval des in FHEM übernommenen Sensors durch die pilight config.json Datei bestimmt, oder? D.h. eigentlich muss ich die mit pilight_temp definierten Sensoren nicht in config.json auflisten, für das Polling-Intervall dann aber trotzdem (bei Sensoren die nicht selber funken).
Genau so ist es.
Zitat von: Funk.Odyssey am 04 Juli 2015, 22:03:47
@Risiko: Könntest du bitte mal einen Blick auf folgenden Random-Timer Thread (http://forum.fhem.de/index.php/topic,14010.msg309471.html#msg309471) werfen? Da haben einige Leute (wie auch ich) Fehler im FHEM-Log und es könnte eventuell mit deinem Modul zu tun haben. Vielleicht hast du ja eine Idee. Danke vielmals.
Hallo Funk.Odyssey,
schaue ich mir bei Gelegenheit an. Bitte aber um etwas Geduld, da ich aktuell sehr wenig Zeit habe.
Risiko
Hallo Risiko,
könntest du bitte dein Modul im offiziellen fhem Repository updaten? Das aktuelle Modul darin funktioniert nicht mehr mit den neuen pilight-daemon. Wenn ich die Version aus deinem git Master nehme läuft alles.
Danke.
Gruß
d.
Häh? Wo hat Risiko denn ein eigenes Git-Repository?
Ich habe Pilight up-to-date und es läuft mit der aktuellen Modul-Version einwandfrei.
Die Frage zielte auf das fhem Repository ab. Wenn man ein "update" macht, werden die Module ja von irgendwo (fhem repository?) geladen, oder?
Verwende ich die Version aus fhem, so erhalten ich folgende Fehlermeldung:
pilight: ERROR. No handshake with pilight-daemon. Received: >>>$data<<<
Wenn ich die Version von hier nehme https://github.com/andreas-fey/fhem-pilight/blob/master/98_pilight.pm, funktioniert alles einwandfrei. Unterschied den ich zur Version in fhem sehe ist, dass dort das oldVersion nicht abgefragt wird.
Meine plight daemon Verison:
pilight-daemon version v7.0-32-g64a0608
In diesem Thread geht es jedoch gar nicht um die Version von Andreas Fey. Die läuft afaik wirklich nur mit dem 5.0er Daemon.
Hier geht es um das Modul "pilight_ctrl", "pilight_switch", etc.
Ok, das erklärt natürlich auch die Verwirrung. Wurde aus meiner Anfrage (http://forum.fhem.de/index.php/topic,39155.0.html) hier her verwiesen.
Wo kann man dann solche Requests stellen, damit Module im Repo aktualisiert werden?
Hmm. Keine Ahnung.
Für dein Modul kenne ich nur diese Threads:
http://forum.fhem.de/index.php/topic,12443.0.html
http://forum.fhem.de/index.php/topic,18252.msg126377.html#msg126377
Ich hatte das auch bis vor kurzem benutzt. Aber ich bin nun wegen der neuen Daemon-Version auf diese Variante gewechselt.
Hallo dominik,
wie dir bereits erklärt wurde, geht es hier nicht um das Modul 98_pilight.pm von A. Fey.
Zitat von: dominik am 14 Juli 2015, 22:32:30
Wo kann man dann solche Requests stellen, damit Module im Repo aktualisiert werden?
A. Fey hat einen eigenen Blog und verwendet ein eigenes git Repository.
Wende dich ggf. direkt an ihn. Hier im Forum ist er scheinbar nicht mehr aktiv.
Oder viel viel besser ;) verwende die hier beschriebenen Module.
Zur Info:
Ich sollte diese Version von ihm testen
https://github.com/andreas-fey/fhem-pilight/tree/beta
was ich natürlich zum Anlass nahm, mit ihm nochmals über eine Zusammenlegung zu diskutieren.
Leider gehen unsere Meinung aber zu weit auseinander, so dass es zu keiner Einigung gekommen ist.
So wird es wohl bei diesem leider unschönen Zustand bleiben, dass es zwei Module gibt.
Risiko
Hallo Risiko,
danke für die Erklärung. Mir war nicht klar, dass deine Module die selbe Funktionalität abdecken.
Generell liegt es mir daran nahe am Standard zu bleiben, damit ich durch zukünftige Updates mir nicht alles zerschieße. Von daher steige ich dann vielleicht auf dein Modul um :)
Gruß
dominik
Hallo Risiko,
dein Modul läuft ja schon eine Weile recht stabil bei mir 8)
Jetzt habe ich mir im Baumarkt ein 4er Set Funksteckdosen gekauft.
Leider werden die (noch) nicht von Pilight unterstützt.
Allerdings bekomme ich sie über pilight-send -p raw --code="...." geschaltet
Mit pilight-raw konnte ich vorher die Werte der Fernbedienung auslesen.
Könntest du eine Sendefunktion für Raw-Werte einbauen? Vermutlich wäre pilight_ctrl der richtige Ort dafür, da es an kein spezielles Gerät gebunden ist.
Grüße
Klaus
Zitat von: klausw am 15 Juli 2015, 23:22:59
Könntest du eine Sendefunktion für Raw-Werte einbauen? Vermutlich wäre pilight_ctrl der richtige Ort dafür, da es an kein spezielles Gerät gebunden ist.
Hallo klausw,
ich werde mir mal Gedanken zu dieser Problematik machen. Denke da aber eher an 30_pilight_raw. Aber mal sehen.
Bekommt man von pilight-receive was gemeldet, wenn man in einer zweiten Verbindung raw Befehle sendet?
Risiko
Hi Risiko,
Zitat von: Risiko am 16 Juli 2015, 23:32:20
ich werde mir mal Gedanken zu dieser Problematik machen. Denke da aber eher an 30_pilight_raw. Aber mal sehen.
Bekommt man von pilight-receive was gemeldet, wenn man in einer zweiten Verbindung raw Befehle sendet?
oder so, dann könnten die dummys wegfallen, das hat auch seinen Reiz.
Nein, pilight-receive meldet nichts (vermutlich würde es eine Meldung bringen, wenn der raw Befehl einem bekannten Gerät entspricht, aber in meinem Fall wird über pilight-receive auch nichts erkannt wenn ich auf die Fernbedienung drücke. Daher habe ich mit pilight-raw die Zahlenkolonnen mitgeloggt).
Nichtsdestotrotz werde ich versuchen mich mit dem pilight Entwickler in Verbindung zu setzen. Ich vermute, das nicht nur der Toom diese Teile verkauft.
Klaus
@Risiko: Ist das technisch möglich, die "pilight_switche" auch mit "on-for-timer" & Co. zu schalten. Derzeit ignorieren die Geräte die Ausführung.
set pilight_abcde on-for-timer 100
Zitat von: FunkOdyssey am 17 Juli 2015, 13:42:40
@Risiko: Ist das technisch möglich, die "pilight_switche" auch mit "on-for-timer" & Co. zu schalten. Derzeit ignorieren die Geräte die Ausführung.
set pilight_abcde on-for-timer 100
Aktuell dann wohl nicht. :-\
Muss ich mal schauen, was das Modul dafür machen muss. Habe mich damit noch nicht beschäftigt.
Wir aber kommen :) - wenn mal wieder schlechtes Wetter ist. ;)
Risiko
Kein Problem. Das schöne Wetter ist wichtiger.
Hilfe mein Log wird überflutet bzw der Event Monitor
guigg_gt7000 in 5 Sekunden über 100 repeats wie kann das sein die suche nach einem bestimmten Signal ist so ausgeschlossen.
(//)
Noch ein screenshot in FHEM
habe versucht quigg_gt7000 zu ignorieren ohne erfolg
Zitat von: Tueftler1983 am 21 Juli 2015, 10:37:15
Noch ein screenshot in FHEM
habe versucht quigg_gt7000 zu ignorieren ohne erfolg
Hallo Tueftler1983,
du machst meiner Meinung nach zwei Fehler:
1. Es ist zwar das Basismodul pilight_ctrl definiert aber kein Switch
2. Um
nur dieses Protokoll zu ignorieren lautet die richtige Syntax quigg_gt7000 :* - Bisser ist aber * - also alles ignorieren
Risiko
Hallo also zu 1. Ich habe switches definiert Screenshot 1 und 2
Zu Punkt 2.
habe das ignore im pilight_Ctrl gemacht ohne Erfolg siehe Screenshot im vorigen Post
und im event Monitor habe ich es wie von dir beschrieben im Filter eingetragen bekomme dann aber garnix mehr angezeigt siehe Screenshot 3
hoffe das hilft
Zitat von: Tueftler1983 am 21 Juli 2015, 23:00:50
Hallo also zu 1. Ich habe switches definiert Screenshot 1 und 2
Ok, da sind mehrer angelegt. Im Screenshot 2 sehe ich aber, dass das Protokoll 'impuls' und nicht 'quigg_gt7000' verwendet wird.
Es scheint keinen Switch für das quigg_gt7000 Protokoll mit ID 3136 zu geben.
Zitat von: Tueftler1983 am 21 Juli 2015, 23:00:50
Zu Punkt 2.
habe das ignore im pilight_Ctrl gemacht ohne Erfolg siehe Screenshot im vorigen Post
und im event Monitor habe ich es wie von dir beschrieben im Filter eingetragen bekomme dann aber garnix mehr angezeigt siehe Screenshot 3
hoffe das hilft
Ich verstehe leider nicht, was du eigentlich willst!!!!
Ich meine das Attribut 'ignoreProtocol' von pilight_ctrl und nicht den Eventfilter!!!!
Risiko.
Zitat von: klausw am 15 Juli 2015, 23:22:59
Könntest du eine Sendefunktion für Raw-Werte einbauen? Vermutlich wäre pilight_ctrl der richtige Ort dafür, da es an kein spezielles Gerät gebunden ist.
Hallo klausw,
ich habe ein neues Modul pilight_raw gemacht. Damit kann man:
1. raw-Codes für state on und off als Attribut ablegen und einfach das Modul wie ein Switch verwenden. Es werden dann die raw-Codes gesendet
2. einen beliebigen raw-Code unabhängig vom state senden
Da sourceforge momentan down ist, hier schon mal die Module zum testen.
Risiko
Das Problem was ich habe ist das ich gerne herausfinden würde welches Signal von einem Funk bewegungsmelder gesendet wird aber das geht nicht weil in 10 ca 100 Signale von quigg_gt7000 rein kommt und mein Signal da unter geht.
ich weiß nicht woher dieses quigg_gt7000 Signal kommt hatte es vor 2 Wochen noch nicht im log oder event monitor.
Ich hätte gerne das ich dieses Protokoll sperren kann in plight oder in deinem Modul sodass es mir garnicht mehr angezeigt wird.
Guck mal in den Screenshot das ist dein Modul pilight_Ctrl
da kann man die repeats sehen von ein und dem selben Signal von quigg_gt7000
Gibt es ne Möglichkeit dir ein Video zukommen zu lassen da siehst du wie schnell die repeats hoch rattern.
Hallo Tueftler1983,
ich kann dir leider nicht helfen, wenn du nicht auf die Punkte eingehst und ich dir sozusagen alles aus Nase ziehen muss.
Pilight empfängt die Messages. Alles normal bzw. kann ich da nichts machen. Evtl. liegt es an deinem Empfänger.
Hast du nun die passende Hardware und möchtest die Messages richtig verarbeiten oder geht es dir nur darum eventuelle falsche Meldungen zu unterdrücken?
Risiko
Zitat von: Risiko am 22 Juli 2015, 20:01:21
ich habe ein neues Modul pilight_raw gemacht. Damit kann man:
1. raw-Codes für state on und off als Attribut ablegen und einfach das Modul wie ein Switch verwenden. Es werden dann die raw-Codes gesendet
2. einen beliebigen raw-Code unabhängig vom state senden
Super Arbeit, funktioniert beides 1a :)
Hallo sorry weiß nicht wie ich es richtig ausdrücken soll.
Dieses Protokoll quigg_gt7000 benutze ich nicht, und hätte gerne das dein Modul alle Nachrichten davon ignoriert. Da sonst der event Monitor und log damit überflutet wird.
Habe den Befehl quigg_gt7000 :* - bei dem atribut ignoreProtokoll eingegeben aber in fhem wird wenn ich dein Modul pilight_Ctrl anklicke immernoch angezeigt das im Sekunden Takt befehle von quigg_gt7000 rein kommen angezeigt und im log auch.
Dieses Problem hatte ich vor ca 2 Monaten noch nicht mit dem quigg_gt7000
Als Hardware habe ich wie von dir angeraten die 433mhz superheterodyne Sender und Empfänger
Sorry für die arbeit
Das Problem hat sich geklärt. Meine Frau hatte auf dem Speicher im Karton mit Weihnachtsdeko gekramt und was auf die Fernbedienung von der Weihnachtsbeleuchtung gelegt.
was nur komisch ist ist das ich die Signale von meinen verwendeten Funk Steckdosen nicht mehr in Fhem und auch nicht in pilight_receive sehe aber das ist eine andere baustelle
Es kann die selbe Baustelle gewesen sein. Letzte Woche wurde -ich sage es neutral- hier von meiner besseren Hälfte getestet, wie eine Fernbedienung reagiert, wenn man einen Karton daraufstellt. Und das bei dem Schalter, der ein nötige-Makro auslöst. Der Funkverkehr hat dabei den gesamten Datenverkehr zum und vom RfxTrx433 blockiert, andere Signale kamen weder rein noch raus. Ansonsten funktionierte fhem und ich habe auch erstmal länger suchen müssen. Man vermutet ja auch keinen Karton als Ursache... ;o)
Gesendet von iPhone mit Tapatalk - Tippfehler sind gratis.
Zitat von: Tueftler1983 am 23 Juli 2015, 12:13:16
Hallo sorry weiß nicht wie ich es richtig ausdrücken soll.
Dieses Protokoll quigg_gt7000 benutze ich nicht, und hätte gerne das dein Modul alle Nachrichten davon ignoriert. Da sonst der event Monitor und log damit überflutet wird.
Habe den Befehl quigg_gt7000 :* - bei dem atribut ignoreProtokoll eingegeben aber in fhem wird wenn ich dein Modul pilight_Ctrl anklicke immernoch angezeigt das im Sekunden Takt befehle von quigg_gt7000 rein kommen angezeigt und im log auch.
Na das sind doch mal passende Infos ;)
"quigg_gt7000 :*" - hier ist ein Leerzeichen zu viel. Nur "*" hast du also nicht getestet. Beide Varianten sollte funktionieren, aber nur Auswirkungen für das Log haben.
Events werden trotzdem generiert, das das Reading rcv_raw aktualisiert wird. Das soll so auch sein, damit man ggf. auf neue Protokolle regieren kann.
Der Eventmonitor hat doch einen eigenen Filter.
Das das ständige Senden der Fernbedienung (ist wirklich blöde wenn permanent was darauf liegt ;D) den Empfang anderer Messages verhindert, ist wie du selbst richtig sagst ein ganz anderes Problem.
Risiko.
So Update
bei mir läuft wieder alles reibungslos!
Irgendwas stimmte mit pilight nicht mehr.
habe es deinstalliert und neu installiert dann noch den Port 5000 in der config.json eingetragen und tada... ich empfange auch wieder Signale von meiner verwendeten Fernbedienung.
Danke nochmal für die hilfe
Zitat von: FunkOdyssey am 17 Juli 2015, 13:42:40
@Risiko: Ist das technisch möglich, die "pilight_switche" auch mit "on-for-timer" & Co. zu schalten. Derzeit ignorieren die Geräte die Ausführung.
set pilight_abcde on-for-timer 100
Ab morgen per update.
Natürlich auch off-for-timer, blink, etc.
Risiko
Juchu. Das kann ich super gebrauchen.
Hey die neuen Funktionen sind super. Läuft einwandfrei!
Ich hab per eventMap mein on auf An gemappt.
Lustigerweise steht nun beim "set piswitch on-for-timer 120" der Text "An-for-timer" im Log. Der Rest funktioniert wie gewollt. Nur im Log steht es falsch drin.
Zitat von: FunkOdyssey am 29 Juli 2015, 21:08:10
Ich hab per eventMap mein on auf An gemappt.
Lustigerweise steht nun beim "set piswitch on-for-timer 120" der Text "An-for-timer" im Log. Der Rest funktioniert wie gewollt. Nur im Log steht es falsch drin.
Liegt wohl dann an eventMap :o. Was meinst du denn für ein Log, vom switch?
Ja
Hallo Risiko,
bin gerade dabei, meine pilight switches auf deine Module pilight_ctrl und pilight_switch umzustellen.
pilight ist mit v7.0 installiert. Die pilight Module sowie FHEM sind auf neuestem Stand.
Ich habe Pollin und Intertechno Steckdosen. Beide lassen sich einwandfrei schalten. Bei den Intertechno Steckdosen wird aber im WebFrontend der Zustand nicht angezeigt. Außerdem erhalte ich folgende Meldung im Log nach jedem Schaltvorgang:
2015.08.09 14:18:50 3: my_pilight: Unknown code PISWITCH,arctech_switch,122344,2,on, help me!
2015.08.09 14:19:18 3: my_pilight: Unknown code PISWITCH,arctech_switch,122344,2,off, help me!
Hier ein list eines entsprechenden Device:
list pi_test
Internals:
CFGFN
DEF kaku_switch 122344 2
ID 122344
IODev my_pilight
NAME pi_test
NR 554
PROTOCOL kaku_switch
STATE defined
TYPE pilight_switch
UNIT 2
Attributes:
room Test
Hier der Verbose 5 Log-Auszug von zwei Schaltvorgängen:
set pi_test on
2015.08.09 14:54:04 4: my_pilight(Write): RCV (pilight_switch) -> pi_test,on
2015.08.09 14:54:04 4: my_pilight(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":122344,"unit":2,"on":1}}
2015.08.09 14:54:04 5: my_pilight(SendNonBlocking): queue size 1
2015.08.09 14:54:05 5: my_pilight(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":122344,"unit":2,"on":1}}
2015.08.09 14:54:05 4: my_pilight(Send): RCV -> {"status":"success"}
2015.08.09 14:54:05 5: my_pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":122344,"unit":2,"state":"on"},"repeat":1,"uuid":"0000-02-c5-0a-4278a7"}
2015.08.09 14:54:05 5: my_pilight dispatch PISWITCH,arctech_switch,122344,2,on
2015.08.09 14:54:05 4: pilight_switch_Parse: RCV -> PISWITCH,arctech_switch,122344,2,on
2015.08.09 14:54:06 3: my_pilight: Unknown code PISWITCH,arctech_switch,122344,2,on, help me!
2015.08.09 14:54:06 4: my_pilight(SendDone): message successfully send
set pi_test off
2015.08.09 14:55:31 4: my_pilight(Write): RCV (pilight_switch) -> pi_test,off
2015.08.09 14:55:31 4: my_pilight(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":122344,"unit":2,"off":1}}
2015.08.09 14:55:31 5: my_pilight(SendNonBlocking): queue size 1
2015.08.09 14:55:31 5: my_pilight(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":122344,"unit":2,"off":1}}
2015.08.09 14:55:31 4: my_pilight(Send): RCV -> {"status":"success"}
2015.08.09 14:55:32 5: my_pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":122344,"unit":2,"state":"off"},"repeat":1,"uuid":"0000-02-c5-0a-4278a7"}
2015.08.09 14:55:32 5: my_pilight dispatch PISWITCH,arctech_switch,122344,2,off
2015.08.09 14:55:32 4: pilight_switch_Parse: RCV -> PISWITCH,arctech_switch,122344,2,off
2015.08.09 14:55:33 3: my_pilight: Unknown code PISWITCH,arctech_switch,122344,2,off, help me!
2015.08.09 14:55:33 4: my_pilight(SendDone): message successfully send
Und zur Vollständigkeit noch ein list des pilight controller:
list my_pilight
Internals:
API 6.0
CFGFN
DEF 192.168.8.21:5000 7.0
DeviceName 192.168.8.21:5000
FD 252
NAME my_pilight
NR 524
NTFY_ORDER 50-my_pilight
PARTIAL
RETRY_INTERVAL 60
STATE connected
TYPE pilight_ctrl
Readings:
2015-08-09 15:03:43 rcv_raw {"origin":"sender","protocol":"arctech_switch","message":{"id":122344,"unit":2,"state":"off"},"repeat":1,"uuid":"0000-02-c5-0a-4278a7"}
2015-08-09 14:38:14 state connected
Helper:
CON connected
LAST_RCV_PROTOCOL arctech_switch
LAST_RCV_RAW {"origin":"sender","protocol":"arctech_switch","message":{"id":122344,"unit":2,"state":"off"},"repeat":1,"uuid":"0000-02-c5-0a-4278a7"}
LAST_SEND_RAW {"action":"send","code":{"protocol":["kaku_switch"],"id":122344,"unit":2,"off":1}}
sendQueue:
whiteList:
kaku_switch:122344
Attributes:
room Interfaces
verbose 5
Kann es sein, daß das pilight Modul die Antwort "protocol = arctech_switch" nicht der gesendeten Nachricht mit "protocol = kaku_switch" zuordnen kann? Leider kann ich die Intertechno Steckdosen nicht direkt als "arctech_switch" definieren. Unter dem Sammelbegriff werden offenbar nur eine Reihe von Herstellern zusammengefasst - siehe http://wiki.pilight.org/doku.php/arctech_switch_v7_0 (http://wiki.pilight.org/doku.php/arctech_switch_v7_0)
Tobias
Zitat von: tpm88 am 09 August 2015, 15:17:09
Kann es sein, daß das pilight Modul die Antwort "protocol = arctech_switch" nicht der gesendeten Nachricht mit "protocol = kaku_switch" zuordnen kann? Leider kann ich die Intertechno Steckdosen nicht direkt als "arctech_switch" definieren. Unter dem Sammelbegriff werden offenbar nur eine Reihe von Herstellern zusammengefasst - siehe http://wiki.pilight.org/doku.php/arctech_switch_v7_0 (http://wiki.pilight.org/doku.php/arctech_switch_v7_0)
Hallo Tobias,
ja genau. Das ist ein Problem in pilight und den unterschiedlichen Benennungen für ein Protokoll (brands).
Dafür gibt es das Attribut brands in pilight_ctrl.
In deinem Fall musst du "arctech:kaku" eintragen. Damit arctech durch kaku ersetzt wird. Also arctech_switch zu kaku_switch.
Risiko
Zitat von: Risiko am 09 August 2015, 18:37:07
In deinem Fall musst du "arctech:kaku" eintragen. Damit arctech durch kaku ersetzt wird. Also arctech_switch zu kaku_switch.
Danke - das hatte ich in der CommandRef übersehen :-\ Muß die Hitze sein... 8)
Die Problematik ist mit dem brands Attribut wirklich sehr elegant gelöst.
Tobias
Hallo,
ich hätte mal eine Frage, und zwar, kann man bei dem Modul irgendwie einstellen das nur bei bestimmten Schaltern etwas anspricht bzw. geloggt wird?
z.B. nur wenn ich den Knopf an meiner Fernbedienung drücke.
Ich habe das Problem das meine Log Datei total riesig und unübersichtlich wird mit der Zeit, da alles Protokoliert wird was über funk reinkommt.
Ich würde am liebsten den empfänger austecken, aber dann würden meine Fernbedienungen nicht mehr funktionieren.
Hier mal ein kleiner ausschnitt meiner Log Datei:
2015.08.25 15:55:07 3: pilight(Parse): unknown protocol -> ehome
2015.08.25 15:55:07 3: pilight: Unknown code PISWITCH,elro_800_contact,0,0,opened, help me!
2015.08.25 15:55:07 3: pilight: Unknown code PISWITCH,elro_800_switch,0,0,on, help me!
2015.08.25 15:55:07 3: pilight(Parse): unknown protocol -> daycom
2015.08.25 15:55:07 3: pilight(Parse): unknown protocol -> ev1527
2015.08.25 15:55:35 3: pilight: Unknown code PISWITCH,elro_400_switch,31,31,on, help me!
2015.08.25 15:55:35 3: pilight: Unknown code PISWITCH,elro_800_contact,0,0,opened, help me!
2015.08.25 15:55:35 3: pilight: Unknown code PISWITCH,elro_800_switch,0,0,on, help me!
2015.08.25 15:55:35 3: pilight(Parse): unknown protocol -> daycom
2015.08.25 15:55:35 3: pilight(Parse): unknown protocol -> ev1527
2015.08.25 16:00:12 3: pilight: Unknown code PISWITCH,logilink_switch,0,0,on, help me!
2015.08.25 16:00:12 3: pilight(Parse): unknown protocol -> ehome
2015.08.25 16:00:12 3: pilight: Unknown code PISWITCH,elro_800_contact,0,0,opened, help me!
2015.08.25 16:00:12 3: pilight: Unknown code PISWITCH,elro_800_switch,0,0,on, help me!
2015.08.25 16:00:12 3: pilight(Parse): unknown protocol -> daycom
2015.08.25 16:00:12 3: pilight(Parse): unknown protocol -> ev1527
2015.08.25 16:03:35 3: pilight: Unknown code PISWITCH,conrad_rsl_switch,6,5,off, help me!
2015.08.25 16:04:01 3: pilight: Unknown code PITEMP,tfa,0,-67.77,0,1, help me!
2015.08.25 16:04:13 3: pilight: Unknown code PISWITCH,elro_800_contact,0,0,opened, help me!
2015.08.25 16:04:13 3: pilight: Unknown code PISWITCH,elro_800_switch,0,0,on, help me!
2015.08.25 16:04:13 3: pilight(Parse): unknown protocol -> daycom
2015.08.25 16:04:13 3: pilight(Parse): unknown protocol -> ev1527
2015.08.25 16:08:41 3: pilight: Unknown code PITEMP,teknihall,0,0,0,0, help me!
2015.08.25 16:10:17 3: pilight: Unknown code PISWITCH,kaku_switch_old,31,15,on, help me!
2015.08.25 16:10:55 3: pilight: Unknown code PISWITCH,clarus_switch,F0,0,off, help me!
2015.08.25 16:16:34 3: pilight: Unknown code PITEMP,alecto_wsd17,0,0,,, help me!
2015.08.25 16:16:34 3: pilight: Unknown code PITEMP,alecto_ws1700,0,0,0,0, help me!
2015.08.25 16:16:35 3: pilight: Unknown code PISWITCH,kaku_switch_old,31,15,on, help me!
2015.08.25 16:17:24 3: pilight: Unknown code PISWITCH,cleverwatts,0,all,on, help me!
2015.08.25 16:17:24 3: pilight(Parse): unknown protocol -> ev1527
2015.08.25 16:17:31 3: pilight: Unknown code PISWITCH,cleverwatts,0,all,on, help me!
2015.08.25 16:17:31 3: pilight(Parse): unknown protocol -> ev1527
2015.08.25 16:17:42 3: pilight: Unknown code PISWITCH,kaku_switch_old,31,15,on, help me!
2015.08.25 16:22:07 3: pilight: Unknown code PISWITCH,clarus_switch,F0,0,off, help me!
2015.08.25 16:39:20 3: pilight: Unknown code PISWITCH,pollin,0,0,on, help me!
2015.08.25 16:39:20 3: pilight: Unknown code PISWITCH,elro_400_switch,31,31,on, help me!
2015.08.25 16:39:20 3: pilight: Unknown code PISWITCH,elro_800_contact,0,0,opened, help me!
2015.08.25 16:39:20 3: pilight: Unknown code PISWITCH,elro_800_switch,0,0,on, help me!
2015.08.25 16:39:21 3: pilight(Parse): unknown protocol -> ev1527
2015.08.25 16:42:55 3: pilight: Unknown code PITEMP,alecto_ws1700,0,0,0,0, help me!
2015.08.25 16:46:21 3: pilight: Unknown code PITEMP,tfa,0,-67.77,0,1, help me!
2015.08.25 16:47:42 3: pilight: Unknown code PITEMP,tfa,0,-67.77,0,1, help me!
2015.08.25 16:49:31 3: pilight(Parse): unknown protocol -> sc2262
2015.08.25 16:51:13 3: pilight: Unknown code PITEMP,alecto_wsd17,0,0,,, help me!
2015.08.25 16:51:13 3: pilight: Unknown code PITEMP,alecto_ws1700,0,0,0,0, help me!
2015.08.25 17:00:29 3: pilight: Unknown code PISWITCH,cleverwatts,0,all,on, help me!
2015.08.25 17:00:29 3: pilight(Parse): unknown protocol -> ev1527
2015.08.25 17:15:45 3: pilight(Parse): unknown protocol -> sc2262
Und davon kann ich gar nichts gebrauchen.
Ich denke mal das es nicht möglich sein wird, da ja die ganze Zeit "gelauscht" werden muss ob etwas passiert.
Aber fragen kann ich ja mal, vieleicht geht das ja doch irgendwie. ;D
Zitat von: TheDestroyer am 25 August 2015, 17:28:06
Hallo,
ich hätte mal eine Frage, und zwar, kann man bei dem Modul irgendwie einstellen das nur bei bestimmten Schaltern etwas anspricht bzw. geloggt wird?
z.B. nur wenn ich den Knopf an meiner Fernbedienung drücke.
Ein Blick in die commandref hilft 8):
Attribut für pilight_ctrl:
ignoreProtocol
Comma separated list of protocol:id combinations to ignore.
protocol:* ignores the complete protocol.
* All incomming messages will be ignored. Only protocol id combinations from defined submodules will be accepted
Example:
ignoreProtocol tfa:0
ignoreProtocol tfa:*
ignoreProtocol *
Ok, das ist wirklich peinlich. :o
Muss leider zugeben das ich da nicht reingeschaut habe. :-\
Vielen Vielen Dank für die schnelle Antwort. ;)
Guten Tag,
Ich wollte hier nochmal paar Sachen nachfragen:
Und zwar wird es eine unterstützung für GPIO geben in bezug auf das AD-Hoc Netzwerk von pilight wichtig wäre hier ein integration zum ansprechen der UUID von pilight. Zurzeit gibt es das ja noch nicht.
Desweiteren besitze ich eine Wetterstation die mir in pilight Temp, Feuchtigkeit, Wind Geschwindigkeit und Win Rictung anzeigt wird es da noch eine integration geben?
Im Grunde genommen finde ich pilight gar nicht so schlecht ich will jetzt hier keineswegs Werbung dafür machen. Leider fehlen dort einige wichtige Features wie das anpassen der config über das WebGui, Zeitschaltung, usw. Man kann es zwar in der config mit Regeln erstellen dies ist aber sehr mühsam und nicht gerade einfach da wiederum gefällt mir FHEM um einiges besser wie pilight.
Meine aktuelle HomeSteuerung besteht aus:
3 Rpi
davon einer im Aqaurium Schrank zur Steuerung von Licht über GPIO und einer 8fachen Relais karte und messen der Temperatur
einer RPi als Haupt Server daran angeschlossen sind ein DHT22, BMP180 und die 433Mhz Sender empfänger
der 3. RPi hängt an einem weiteren Aquarium zur einfachen Temperatur messung.
einigen 433MHz Funksteckdosen,
3 TFA Raumsensoren Temp/Luftfeuchtigkeit.
Ich denke es wird sich da bestimmt noch was tun.
Was wäre den vom @Risiko in Zukunft geplant um halt meine weitere Planung erstellen zu können.
Zitat von: danieljo am 29 August 2015, 13:56:29
Und zwar wird es eine unterstützung für GPIO geben in bezug auf das AD-Hoc Netzwerk von pilight wichtig wäre hier ein integration zum ansprechen der UUID von pilight. Zurzeit gibt es das ja noch nicht.
Dazu benötige ich noch etwas mehr Infos. Geht es hier um das relay-Protokoll und\oder gibt es bezüglich AD-Hoc noch weitere Dinge zu beachten. Habe mich damit noch nicht beschäftigt.
Zitat von: danieljo am 29 August 2015, 13:56:29
Desweiteren besitze ich eine Wetterstation die mir in pilight Temp, Feuchtigkeit, Wind Geschwindigkeit und Win Rictung anzeigt wird es da noch eine integration geben?
Temperatur und Feuchtigkeit sollten jetzt schon gehen. Die anderen Dinge lassen sich sicherlich einfach und zeitnah erweitern.
Um welches Protokoll handelt es sich?
Zitat von: danieljo am 29 August 2015, 13:56:29
Was wäre den vom @Risiko in Zukunft geplant um halt meine weitere Planung erstellen zu können.
Wenn die Anforderungen klar formuliert, allgemeingültig genug sind und du beim Testen unterstützt (habe nicht all die Hardware), dann bin ich gern bereit das Modul weiter dahin zu entwickeln. Natürlich nur so wie es meine Zeit erlaubt.
Risiko.
Danke für das Anbieten deiner Hilfe.
Also um das sogenannten "Ad-hoc netzwerk" in pilight geht sich darin in erster linie zwei seperate RPi mit installierten Pilight über das Netzwerk (LAN) miteinander zu Verbinden. Ähnlich dem FHEM2FHEM.
Dabei fungiert der "Haupt RPi" als Master-Deamon und jedes weitere Remote Pilight als Client der sich mit dem Deamon verbindent. Das Remote Gerät bekommt eine eigenständige eindeutige UUID "Device ID" um mit dem Master Deamon ein Gerät zuschalten/Temp Sensoren zu lesen muss man die UUID des client angeben.
Da aber gerade in meiner Verwendung die Verbindung andauern Reset werden sprich: der Client/Deamon verliert die Verbinung und beim Reconnect werden alle Relais ausgänge zurückgesetzt. Wenn mein Aquarium da nicht dran hängen würde wäre es mir egal aber Wenn am Tag 20mal immer alles ausgeht ist das äußerst schelcht. Der autor von pilight curlymo hat das seit 2 - 3 monaten immer noch nicht behoben. Ich habe mir den Code zwar so umgeschrieben das die Relais nicht mehr zurückgesetzt werden aber nach einem connection lost sind in der WebGui alle Schalter auf aus.
Deshalb werde ich hier auf FHEM umsteigen und die Relais über GPIO aus FHEM ansteuern über FHEM2FHEM ich hoffe das funktioniert ohne Probleme. Daher werde ich dies Testen
Zur Wetterstation: In pilight hört diese auf das Protocoll "alecto_wx500" Temperatur und Luftfeuchtigkeit geht ohne Probleme. Windrichtung und Windgeschwindigkeit und Regenmenge sind bereits integriert. Wobei die Regenmenge nicht implementiert ist weil der autor keine Möglichkeit hat die Werte in einer Datenbank oder im Textformat zu speichern. Deshalb denke ich das es mit der Regenmenge im FHEM auch nix geben wird!
Natürlich kann ich beim Testen helfen. Hardware und Zeit hätte ich. Da kann ich dich unterstüzen. Fürs erste reicht mir wenn für die Wetterstation noch die Windgeschwindigkeit und Windrichtung angezeigt werden könnte.
Die Sache mit dem UUID lassen wir erstmal beiseite liegen. Da dies von pilight aus nur mangelhaft gelöst ist und das meinen Informationen nach auch mit FHEM2FHEM und RPI_GPIO zu lösen sein sollte.
Zitat von: danieljo am 30 August 2015, 11:47:45
Natürlich kann ich beim Testen helfen. Hardware und Zeit hätte ich. Da kann ich dich unterstüzen. Fürs erste reicht mir wenn für die Wetterstation noch die Windgeschwindigkeit und Windrichtung angezeigt werden könnte.
So ab morgen stehen neue Readings (pressure, windavg, winddir und windgust) für pilight_temp zur Verfügung. Natürlich nur, wenn der Sensor|Wetterstation dies unterstützt.
Zugegeben pilight_temp ist vom Namen her jetzt nicht mehr ganz passend, aber ein Umbenennen des Moduls (z.B. in pilight_weatherstation ) macht zu viel Ärger. Zwei Module mit fast gleichen Readings macht die Pflege aufwendig. Deshalb (erstmal) so.
Zum Thema GPIO-switch
Ich finde es etwas seltsam (oder ich verstehe da was völlig falsch), dass pilight dafür zwei Protokolle "gpio_switch" zum Empfangen und "relay" zum Senden vorsieht.
Mit den Beiden wäre es aber aus meiner Sicht möglich, einen Schalter bereit zu stellen bzw. in pilight_switch zu integrieren.
Risiko.
Vielen Dank für die äußerst schnelle implementierung der zusätzlichen Werte. Ja du hast recht "pilight_temp" wäre durchaus jetzt fehl am Platz aber ich würde es auch so lassen wie es jetzt ist. Diesen jetzt zu ändern sorgt nur für unnötige Verwirrung.
Zum Thema GPIO_Switch und GPIO_Relay. Es besteht ein unterschied zwischen diesen beiden Protokollen:
GPIO_Switch kann nur eingänge lesen und den Wert anzeigen
GPIO_Relay kann nur Ausgänge schalten
Warum da so gemacht worden ist keine Ahnung habe zuers auch gedacht das beide Protokolle beides können.
Ich werde deine Änderungen nachher mal testen. Ein Update in FHEM sollte denke ich reichen oder?
MFG, Daniel Joachims
Also ich habe gerade das Update durchgeführt und wurde über die änderungen in pilight_temp informiert. Mit einem "shutdown restart" FHEM neugestartet.
Danach steht in meiner Wetterstation Definition nur "STATE DEFINED"
Im FHEM log werden zumindestens Daten empfangen.
2015-08-31 17:28:04 pilight_ctrl myctrl rcv_raw: {"message":{"id":236,"winddir":315,"windgust":0.6,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
Hallo habe noch eine Frage bzw Problem.
Eine Funksteckdose mag nicht immer schalten.
Auf den einschalten Befehl reagiert sie eigentlich immer,
Aber auf den ausschalten Befehl fast nie. Ist es möglich das der ausschalte Befehl mehrfach gesendet wird?
Also ich sag ausschalten und der Befehl wird automatisch 5 mal in 5 sek gesendet?
Danke dir schonmal
Zitat von: danieljo am 31 August 2015, 17:30:46
Danach steht in meiner Wetterstation Definition nur "STATE DEFINED"
Im FHEM log werden zumindestens Daten empfangen.
Kannst du bitte mal das verbose des pilight_temp auf 5 stellen und dann schauen, was im Log ankommt.
Ggf. auch das verbose von pilight_ctrl auf 4. Danke.
Wurde vor dem Update das Temperature-Reading ordnungsgemäß aktualisiert?
Risiko.
Zitat von: Tueftler1983 am 31 August 2015, 22:32:58
Aber auf den ausschalten Befehl fast nie.
Schaltet nur die Hardware nicht aber state ist i.O. - also off oder ist auch der state nicht in Ordnung - bleibt auf on?
Zitat von: Tueftler1983 am 31 August 2015, 22:32:58
Ist es möglich das der ausschalte Befehl mehrfach gesendet wird?
Also ich sag ausschalten und der Befehl wird automatisch 5 mal in 5 sek gesendet?
Aktuell nicht.
Denke, dass bekommt man mit notify und\oder DOIF auch hin.
Wenn mehrere so ein Problem\Wunsch haben, würde ich es wahrscheinlich einbauen - also eine Repeat-Funktionalität.
Risiko
Hallo
Der state zeigt off aber die Hardware bleibt an.
Wäre schön wenn da was gehen würde wenn nicht mach ich da nix dran.
Danke dir
Ich werde es morgen ausprobieren und Rückmeldung geben was im Verbose steht. Ja vor dem Update wurde mir die Temperatur und Luftfeuchtigkeit angezeigt.
Mfg, Daniel Joachims
Hallo Tueftler1983
vielleicht sowas in der Richtung:
define di_repeat_off DOIF ([switch_name:?.*off]) (set switch_name off)(set switch_name off)(set switch_name off)(set switch_name off)
attr di_repeat_off wait 5,5,5,5
switch_name durch den entsprechenden Namen ersetzen.
Risiko
Also ich habe gestern wie gewünscht die "Verbose" auf 5 gestellt.
Vllt. sollte ich erwähnen das meine Wetterstation die Daten niemals gleichzeitig senden. Es werden zu unterschiedlichen Zeiten 3 daten Blöcke gesendet:
"id" "temperature" "humidity" "battery"
"id" "windavg" "battery"
"id" "winddir" "wingust" "battery"
Events (Filter:.*):
2015-09-02 21:39:33 pilight_ctrl myctrl rcv_raw: {"message":{"id":236,"temperature":14.2,"humidity":85.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015-09-02 21:40:04 pilight_ctrl myctrl rcv_raw: {"message":{"id":236,"windavg":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015-09-02 21:40:34 pilight_ctrl myctrl rcv_raw: {"message":{"id":236,"windavg":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015-09-02 21:40:35 pilight_ctrl myctrl rcv_raw: {"message":{"id":236,"winddir":315,"windgust":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":2}
2015-09-02 21:41:06 pilight_ctrl myctrl rcv_raw: {"message":{"id":236,"winddir":315,"windgust":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015-09-02 21:41:37 pilight_ctrl myctrl rcv_raw: {"message":{"id":236,"winddir":315,"windgust":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015-09-02 21:42:38 pilight_ctrl myctrl rcv_raw: {"message":{"id":236,"temperature":14.2,"humidity":85.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1
Kann es sein das dein Modul alle Werte auf einmal erwartet?
Zitat von: danieljo am 02 September 2015, 21:45:29
Vllt. sollte ich erwähnen das meine Wetterstation die Daten niemals gleichzeitig senden. Es werden zu unterschiedlichen Zeiten 3 daten Blöcke gesendet:
"id" "temperature" "humidity" "battery"
"id" "windavg" "battery"
"id" "winddir" "wingust" "battery"
Ah. Gut zu wissen. Das muss ich nochmal prüfen bzw. berücksichtigen.
Benötige aber die Logausschriften und nicht die Events aus dem Eventmonitor!!
Risiko
Die Logeinträge reiche ich dir heute Abend nach
Mfg, Daniel Joachims
Hier die einträge aus der Log-File:
2015.09.01 21:42:12 5: Triggering myctrl (1 changes)
2015.09.01 21:42:12 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"windavg":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015.09.01 21:42:13 5: Triggering myctrl (1 changes)
2015.09.01 21:42:13 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"winddir":315,"windgust":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":2}
2015.09.01 21:42:43 5: Triggering myctrl (1 changes)
2015.09.01 21:42:43 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"windavg":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015.09.01 21:42:43 5: Triggering myctrl (1 changes)
2015.09.01 21:42:43 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"winddir":315,"windgust":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":2}
2015.09.01 21:42:43 5: Triggering myctrl (1 changes)
2015.09.01 21:42:43 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"windavg":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":3}
2015.09.01 21:42:44 5: Triggering myctrl (1 changes)
2015.09.01 21:42:44 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"winddir":315,"windgust":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":4}
2015.09.01 21:43:14 5: Triggering myctrl (1 changes)
2015.09.01 21:43:14 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"winddir":315,"windgust":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015.09.01 21:43:45 5: Triggering myctrl (1 changes)
2015.09.01 21:43:45 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"windavg":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015.09.01 21:43:46 5: Triggering myctrl (1 changes)
2015.09.01 21:43:46 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"winddir":315,"windgust":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":2}
2015.09.01 21:44:16 5: Triggering myctrl (1 changes)
2015.09.01 21:44:16 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"temperature":15.6,"humidity":89.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015.09.01 21:44:16 4: pilight_temp_Parse: RCV -> PITEMP,alecto_wx500,236,15.6,89,1
2015.09.01 21:44:47 5: Triggering myctrl (1 changes)
2015.09.01 21:44:47 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"winddir":315,"windgust":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015.09.01 21:44:48 5: Triggering myctrl (1 changes)
2015.09.01 21:44:48 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"windavg":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":2}
2015.09.01 21:45:19 5: Triggering myctrl (1 changes)
2015.09.01 21:45:19 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"windavg":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015.09.01 21:45:49 5: Triggering myctrl (1 changes)
2015.09.01 21:45:49 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"windavg":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015.09.01 21:45:49 5: Triggering myctrl (1 changes)
2015.09.01 21:45:49 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"winddir":315,"windgust":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":2}
2015.09.01 21:46:21 5: Triggering myctrl (1 changes)
2015.09.01 21:46:21 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"windavg":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015.09.01 21:46:51 5: Triggering myctrl (1 changes)
2015.09.01 21:46:51 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"windavg":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015.09.01 21:46:52 5: Triggering myctrl (1 changes)
2015.09.01 21:46:52 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"winddir":315,"windgust":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":2}
2015.09.01 21:47:22 5: Triggering myctrl (1 changes)
2015.09.01 21:47:22 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"temperature":15.6,"humidity":89.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015.09.01 21:47:22 4: pilight_temp_Parse: RCV -> PITEMP,alecto_wx500,236,15.6,89,1
2015.09.01 21:47:53 5: Triggering myctrl (1 changes)
2015.09.01 21:47:53 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"winddir":315,"windgust":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
2015.09.01 21:47:54 5: Triggering myctrl (1 changes)
2015.09.01 21:47:54 5: Notify loop for myctrl rcv_raw: {"message":{"id":236,"winddir":315,"windgust":0.0,"battery":1},"origin":"receiver","protocol":"alecto_wx500","uuid":"0000-b8-27-eb-f7c908","repeats":1}
Hallo Daniel,
habe sie Sache heut (hoffentlich) gefixt. Ab morgen dann per Update verfügbar.
Risiko
Wunderbar. Ich bedanke mich schonmal vorab bei dir und werde es morgen testen und dir Rückmeldung geben.
MFG, Daniel Joachims
Also irgendwie funktioniert das noch nicht.
Ich bekomme zwar in den Readings battery;humidity,state,temperature richtiger weise angeizeigt, aber der Rest fehlt.
Zitat von: danieljo am 07 September 2015, 18:56:31
Also irgendwie funktioniert das noch nicht.
Ich bekomme zwar in den Readings battery;humidity,state,temperature richtiger weise angeizeigt, aber der Rest fehlt.
Hmm. Stelle bitte verbose von pilight_ctrl auf 4 und überwache mal die Logs von pilight_temp_Parse: RCV -> PITEMP,alecto_wx500.....
Leider kann ich das ohne Hardware auch nicht simulieren.
Risiko.
Das ist die ausgabe von pilight_ctrl verbose 4:
2015.09.07 20:20:16 4: pilight_temp_Parse: RCV -> PITEMP,alecto_wx500,236,15.5,82,1
2015.09.07 20:20:16 4: pilight_temp_Parse: RCV -> PITEMP,alecto_wx500,236,15.5,82,1
2015.09.07 20:20:17 4: pilight_temp_Parse: RCV -> PITEMP,alecto_wx500,236,15.5,82,1
2015.09.07 20:20:17 4: pilight_temp_Parse: RCV -> PITEMP,alecto_wx500,236,15.5,82,1
2015.09.07 20:23:22 4: pilight_temp_Parse: RCV -> PITEMP,alecto_wx500,236,15.4,82,1
2015.09.07 20:23:22 4: pilight_temp_Parse: RCV -> PITEMP,alecto_wx500,236,15.4,82,1
2015.09.07 20:23:23 4: pilight_temp_Parse: RCV -> PITEMP,alecto_wx500,236,15.4,82,1
2015.09.07 20:23:23 4: pilight_temp_Parse: RCV -> PITEMP,alecto_wx500,236,15.4,82,1
Nabend
Sieht für mich nach ner alten Version aus. Was sagt version? - Befehl in der Befehlszeile eingeben
pilight_temp muss in Version 0.16 und pilight_ctrl in 1.11 vorliegen.
Risiko
Also version sagt folgendes:
# $Id: 10_pilight_ctrl.pm 1.11 2015-09-06 Risiko $
# $Id: 30_pilight_temp.pm 0.16 2015-09-06 Risiko $
Ist somit also aktuell.
Also die Logausschriften passen definitiv nicht zur Version!
Hast du FHEM nach dem Update nicht neu gestartet?
Risiko
Na klar habe ich ein "shutdown restart" gemacht. Wenn du selber schauen möchtest kann ich dir per PN remote zugriff geben dann kannst du selber schauen ist wahrscheinlich effektiver oder?
Mfg, Daniel Joachims
Okey anscheinend funktioniert es nun. Das einzige was geändert worden ist das ich den "featureLevel" in global gesetzt habe
MFG, Daniel Joachims
Hallo,
ich habe Probleme den pilight Service anzusprechen. Habe pilight auf localhost:5001 laufen:
curl http://127.0.0.1:5001/send?%7B%22action%22%3A%22identify%22%2C%22options%22%3A%7B%22receiver%22%3A1%7D%2C%22media%22%3A%22all%22%7D
{"message":"success"}
Wenn ich den Service aus FHEM anspechen möchte, kann sich FHEM nicht verbinden:
2015.09.14 10:55:04 5: pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2015.09.14 10:55:04 4: pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2015.09.14 10:55:04 5: SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2015.09.14 10:55:07 5: pilight(Check): opened
2015.09.14 10:55:07 4: pilight(Check): Could not connect to pilight-daemon localhost:5001 - maybe wrong api version or port
2015.09.14 10:55:07 1: localhost:5001 disconnected, waiting to reappear (pilight)
Eingebunden ist der Service:
Internals:
API 6.0
CFGFN
DEF localhost:5001
DevIoJustClosed 1
DeviceName localhost:5001
NAME pilight
NR 110
NTFY_ORDER 50-pilight
PARTIAL
RETRY_INTERVAL 60
STATE disconnected
TYPE pilight_ctrl
Readings:
2015-09-14 10:56:21 state disconnected
Helper:
CHECK 0
CON disconnected
NEXT_TRY 1442221041.48406
sendQueue:
whiteList:
Attributes:
verbose 5
Könnte es etwas mit der Url-Codierung sein?
Version der module ist:
$Id: 10_pilight_ctrl.pm 1.12 2015-09-11 Risiko $
Gelöst: Es war wie bei einigen Beiträgen vorher der Port.
"port": 5000,
"webserver-port": 5001,
Nach hinzufügen vom port parameter in der pilight config geht es.
Hallo,
da nun fhem fleissig meine Aussensensoren über pilight abfragt und sie ins Log-File schreibt:
2015.09.15 07:36:44 4: pilight_temp_Parse: RCV -> PITEMP,alecto_ws1700,1487,temperature:11.1,humidity:21,battery:1
würde ich sie auch gerne in ein SVG-Plot packen.
Leider bekomme ich das nicht hin. Egal welche Spalte ich vom Log-File auswähle bekomme ich keine Werte.
Kann ich die Ausgabe vom pilight_temp_Parse in ein anderes Log-File ausgeben und das Format anpassen?
Geschafft:
Ich habe es über ein eignes LogiFile realisiert:
define FileLog_PilightTempAussen FileLog ./log/PilightTempAussen-%Y.log PilightTempAussen|PilightTempAussen:temperature:.*
Damit kann ich die Daten wunderbar plotten.
Hallo Tom71,
schön das alles funzt und du dir selbst deine Fragen beantworten kannst ;)
Weiterhin viel Erfolg.
Risiko.
Erstmal, ich danke Ihnen für dieses Modul! Sorry für mein Deutsch. Gibt es irgendwelche Pläne, um den Kontakt Sensoren von pilight zu implementieren? Wäre toll, Wireless-Kontaktsensoren wie kaku_contact in FHEM übernehmen (beispielsweise über notify).
Danke für deine Antwort.
Hallo rbardoel,
sollte mit dem Attribut ContactAsSwitch von pilight_ctrl und einem switch (kaku_switch) jetzt schon gehen.
Kann es mir nach meinem Urlaub gern nochmal ansehen.
Hallo....
ich benutze piLight zum schalten von intertechno funksteckdosen...
leider habe ich einen Fehler im LOG.
2015.10.05 19:05:32 1: Including /opt/fhem/mycfg/02_pilight.cfg
splice on reference is experimental at ./FHEM/10_pilight_ctrl.pm line 187.
splice on reference is experimental at ./FHEM/10_pilight_ctrl.pm line 545.
2015.10.05 19:05:34 3: Opening pilight_daemon device localhost:5000
2015.10.05 19:05:34 3: pilight_daemon device opened
....
....
2015.10.05 19:05:35 1: PERL WARNING: Calling POSIX::isdigit() is deprecated at ./FHEM/10_pilight_ctrl.pm line 284.
jemand einen Rat?
Hallo remet,
kann da keine Fehler sondern nur Warnungen und Hinweise sehen. Was genau geht nicht?
Welche Perlversion verwendet du?
Risiko
Zitat von: Tom71 am 15 September 2015, 07:50:07
Hallo,
da nun fhem fleissig meine Aussensensoren über pilight abfragt und sie ins Log-File schreibt:
2015.09.15 07:36:44 4: pilight_temp_Parse: RCV -> PITEMP,alecto_ws1700,1487,temperature:11.1,humidity:21,battery:1
würde ich sie auch gerne in ein SVG-Plot packen.
Leider bekomme ich das nicht hin. Egal welche Spalte ich vom Log-File auswähle bekomme ich keine Werte.
Kann ich die Ausgabe vom pilight_temp_Parse in ein anderes Log-File ausgeben und das Format anpassen?
Geschafft:
Ich habe es über ein eignes LogiFile realisiert:
define FileLog_PilightTempAussen FileLog ./log/PilightTempAussen-%Y.log PilightTempAussen|PilightTempAussen:temperature:.*
Damit kann ich die Daten wunderbar plotten.
Wie schaffe ich es überhaupt, das pilight-ctrl angesprochen wird ?
Habe das Problem, sobald ich pilight_ctrl über define einsetzt, dass die Fehlermeldung kommt, dass das Modul nicht geladen werden kann.
Habe FHEM über Update auf den neusten Stand gebracht, danach funktionierte das Senden von Befehlen an pilight nicht mehr.
#EG_wz_EckeLicht
define EG_wz_EckeLicht dummy
attr EG_wz_EckeLicht group Licht
attr EG_wz_EckeLicht room Wohnzimmer
attr EG_wz_EckeLicht setList on off
define on_EG_wz_EckeLicht notify EckeLicht:on "pilight-send -p elro_800_switch -s 31 -u 1 -t"
define off_EG_wz_EckeLicht notify EckeLicht:off "pilight-send -p elro_800_switch -s 31 -u 1 -f"
Hat da jemand einen Lösungsansatz ?
Vor dem Update hat dies alles noch funktioniert.
Danke.
Zitat von: sash.sc am 15 Oktober 2015, 09:55:18
Wie schaffe ich es überhaupt, das pilight-ctrl angesprochen wird ?
Habe das Problem, sobald ich pilight_ctrl über define einsetzt, dass die Fehlermeldung kommt, dass das Modul nicht geladen werden kann.
Habe FHEM über Update auf den neusten Stand gebracht, danach funktionierte das Senden von Befehlen an pilight nicht mehr.
#EG_wz_EckeLicht
define EG_wz_EckeLicht dummy
attr EG_wz_EckeLicht group Licht
attr EG_wz_EckeLicht room Wohnzimmer
attr EG_wz_EckeLicht setList on off
define on_EG_wz_EckeLicht notify EckeLicht:on "pilight-send -p elro_800_switch -s 31 -u 1 -t"
define off_EG_wz_EckeLicht notify EckeLicht:off "pilight-send -p elro_800_switch -s 31 -u 1 -f"
Hat da jemand einen Lösungsansatz ?
Vor dem Update hat dies alles noch funktioniert.
Danke.
Hast du nach dem Update auch ein "shutdown restart" durchgeführt?
Zitat von: sash.sc am 15 Oktober 2015, 09:55:18
Wie schaffe ich es überhaupt, das pilight-ctrl angesprochen wird ?
Habe das Problem, sobald ich pilight_ctrl über define einsetzt, dass die Fehlermeldung kommt, dass das Modul nicht geladen werden kann.
Habe FHEM über Update auf den neusten Stand gebracht, danach funktionierte das Senden von Befehlen an pilight nicht mehr.
#EG_wz_EckeLicht
define EG_wz_EckeLicht dummy
attr EG_wz_EckeLicht group Licht
attr EG_wz_EckeLicht room Wohnzimmer
attr EG_wz_EckeLicht setList on off
define on_EG_wz_EckeLicht notify EckeLicht:on "pilight-send -p elro_800_switch -s 31 -u 1 -t"
define off_EG_wz_EckeLicht notify EckeLicht:off "pilight-send -p elro_800_switch -s 31 -u 1 -f"
Hallo sash.sc,
verstehe leider nicht so richtig was du meinst. Du verwendest doch im Code einen dummy und kein pilight_switch und kein pilight_ctrl.
Wie sehen den die Fehlermeldungen im Log aus?
Ich hatte versucht das modul pilight_ctrl zu definieren. Habe die cfg gespeichert und dabei kam die Meldung, dass das Modul nicht geladen werden kann.
Warum auch immer.
Mit dem Sendekommando wie ich es oben definiert hatte, hatte auch alles funktioniert, bis ich das Update gemachte hatte. In der Log steht gar nix drin.
Habe im Moment das Problem, das FHEM über den browser nicht zu erreichen ist. Habe es geschaft, das zumindest wieder in die log datei geschrieben wird.
greez
Sascha
Wenn du mit pilifht_temp schon Werte empfangen hast, muss pilight_ctrl schon funktioniert haben. Es wird übrigens nur einmal benötigt.
Empfangen habe ich noch nix. Habe bis jetzt mit den pilight Modulen noch nicht gearbeitet. Das ganze Pilight Kommando steht in " " .
Pilight wird nur als externes programm aufgerufen, ohne mit den Modulen zu arbeiten.
@danieljo ja habe einenshutdown und restart durchgeführt.
Hallo, bin neu hier , hab mich gerade angemeldet weil ich nicht weiter komme.
habe fhem und pilight auf nem raspi am laufen. pilight funzt auch so wie es soll...
bekomme aber keine Verbindung zu fhem hin. fhem hab ich upgedatet und pilight ist Version 7.0...
wenn ich versuche pilight_ctrl zu definieren:
define myctrl pilight_ctrl 192.x.x.x:5000
sagt fhem immer
"cannot load modul pilight ctrl"
hab schon alles mögliche gelesen und probiert.
"port": 5000 - hab ich in die config.json eingetragen.
im fhem log gibt er folgendes aus:
2015.10.16 19:09:57 1: reload: Error:Modul 10_pilight_ctrl deactivated:
Can't locate Switch.pm in @INC (you may need to install the Switch module) (@INC contains: /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/10_pilight_ctrl.pm line 47.
BEGIN failed--compilation aborted at ./FHEM/10_pilight_ctrl.pm line 47.
2015.10.16 19:09:57 0: Can't locate Switch.pm in @INC (you may need to install the Switch module) (@INC contains: /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/10_pilight_ctrl.pm line 47.
BEGIN failed--compilation aborted at ./FHEM/10_pilight_ctrl.pm line 47.
haha, ich noob hab es hin bekommen
sudo apt-get update && sudo apt-get install libswitch-perl -y
did the trick... ;D ;D ;D ;D ;D
erste sahne läuft genau so wie es soll...
vielen dank für das modul.....
bis die tage
stadtkind
Hallo,
ich nutze das pilight Modul für alle meine 433MHz Funksteckdosen. Wie wir aber wissen, haben diese keine 100% Zuverlässigkeit aufgrund des mangelnden Rückkanals bei vielen Modellen. Da die Verfügbarkeit damit auf ca. 99% (Gefühl) sinkt, habe ich überlegt, ob man nicht pilight_ctrl erweitert und dort jeden Send Befehl 2x schickt. Oder man definiert es bei pilight_switch und gibt dort an, dass für manche Funksteckdosen der Befehle x-mal gesendet werden soll.
Denn 99% Verfügbarkeit birgt große Risiken, dass gerade die "off" Befehle nicht ankommen und so manche Verbraucher über einen Tag oder länger eingeschaltet bleiben. Für meine Außenbeleuchtung sende ich daher 2 off Befehle. Damit komm ich näher an die 100% Verlässlichkeit des Systems ran :)
Das soll nur mal ein schneller Vorschlag sein, vielleicht hat noch jemand bessere Ideen wie man das verbessern kann? Bessere Sender sind aber meiner Ansicht nach nicht die Lösung, da es eben oft auch am Empfänger der Funksteckdose liegt.
Hi,
nachdem ich nun 4 Stunden gegoogelt habe -hoffe ich das mir hier jemand helfen kann.
Wenn ich in fhem folgenden Code eingebe:
define Steckdose1 pilight_switch elro_800_switch 10 1
funktioniert alles.
Welchen Code müsste ich verwenden wenn ich ein Intertechno-Gerät so schalten möchte?
Die beiden Drehräder stehen auf J und auf 10 - ich komme leider anders nicht mehr weiter.
Grüße, Smeagel
Anstatt elro_800_switch gibst du intertechno ein deine id mit dem "j" müsstest du umrechnen und nicht vergessen die Unit anzugeben, sprich die Steckdosen Nummer.
Die Idee mir dem Befehl mehrfach senden ist nicht schlecht. Bei pilight 5.0 könnte man in der config. Json noch die Anzahl der repeats eingeben. Seit der 6.0 nicht mehr
Gesendet von meinem C6603 mit Tapatalk
Hi,
habe habe schon folgendes versucht:
define Steckdose1 pilight_switch intertechno F00F F00F
allerdings ohne Erfolg.
Grüße, Smeagel
Es gibt, glaube ich, eine Seite, wo man die Codes von den Herstellern umrechnen kann. Versuch es mal mit dezimal zahlen. Habe auch intertechno Komponenten, selbst lernende, die haben eine 8 stellige, dezimal, id. Und es klappt.
Gesendet von meinem C6603 mit Tapatalk
Hi,
es klappt weder:
define Schalter_ME_A2 pilight_switch intertechno 1001 1001
define Schalter_ME_A2 pilight_switch intertechno F00F F00F
define Schalter_ME_A2 pilight_switch intertechno J 10
Wo liegt blos der Fehler?
Hallo.
Ich meine mit dem Protokoll "intertechno" sind die selbstlernenden Intertechno Schalter\Dosen gemeint. Die ID ist hier eine 8-Stellige Nummer und die Unit beginnt bei Null.
Für die älteren Schalter\Dosen mit einem Dip-Schalter wird das Protokoll "intertechno_old" benötigt. Hier beginnen ID und Unit bei Null.
Am einfachsten bekommt man das mit pilight-receive raus (Empfänger natürlich vorausgesetzt).
Risiko.
Zitat von: dominik am 17 Oktober 2015, 09:19:15
Hallo,
ich nutze das pilight Modul für alle meine 433MHz Funksteckdosen. Wie wir aber wissen, haben diese keine 100% Zuverlässigkeit aufgrund des mangelnden Rückkanals bei vielen Modellen. Da die Verfügbarkeit damit auf ca. 99% (Gefühl) sinkt, habe ich überlegt, ob man nicht pilight_ctrl erweitert und dort jeden Send Befehl 2x schickt. Oder man definiert es bei pilight_switch und gibt dort an, dass für manche Funksteckdosen der Befehle x-mal gesendet werden soll.
Denn 99% Verfügbarkeit birgt große Risiken, dass gerade die "off" Befehle nicht ankommen und so manche Verbraucher über einen Tag oder länger eingeschaltet bleiben. Für meine Außenbeleuchtung sende ich daher 2 off Befehle. Damit komm ich näher an die 100% Verlässlichkeit des Systems ran :)
Das soll nur mal ein schneller Vorschlag sein, vielleicht hat noch jemand bessere Ideen wie man das verbessern kann? Bessere Sender sind aber meiner Ansicht nach nicht die Lösung, da es eben oft auch am Empfänger der Funksteckdose liegt.
Aus diesem Grund sollte man meiner Meinung nach solche Technik auch nicht für kritische Sachen einsetzen. Ob bspw. der Switch auch wirklich aus ist, sollte man meiner Meinung nach immer gleich sehen und zur Not eben manuell nochmal off senden\drücken.
Das N-malige senden wird das Problem sicherlich verbessern, ab nie beheben können. Es könnte aber auch Nachteile haben, z.B. wenn man mittels einer Struktur viele Schalter auf einmal schalten möchte. Dann kommt es sicherlich zu deutlichen Verzögerungen und die Schalter schalten hintereinander und nicht gleichzeitig.
Es gibt auch Kommandos, die man nicht wiederholt senden will. Z.B. sowas wie Up\Down für Dimmer. Daher ist zentral in pilight_ctrl nicht die richtige Stelle.
In pilight_switch könnte ich mir schon vorstellen ein "Sende-Repeat N" einzubauen.
Risiko.
Hallo, ich hoffe ich bin hier richtig..ansonsten bitte verschieben
Ich habe mir für einen intertechno itwr-3500 einen pilight_switch angelegt:
Define Lampe.nebeneingang pilight_switch intertechno_switch 1234 1
Funktioniert einwandfrei und schaltet wie er soll.
Aber leider zeigt er mir keine devstateicons an da steht immer nur "defined"...
Was muss ich tun um mir da den "schaltzustand" also ob ich auf an oder aus geschaltet habe anzeigen zu lassen? Is wahrscheinlich ne total blöde Anfängerfrage, wäre für jeden Tipp dankbar.
Mit freundlichen Grüßen stadtkind
Hallo Stadtkind.
Das gleiche ist bei mir auch. Habe aber festgestellt, dass dies vom verwendeten Protokoll abhängig ist. Beim ELRo Protokoll werden Lampen angezeigt, je nach Zustand.
Aber sonst mach pilight_switch was es soll !!! :)
greez
Sascha
Hallo,
ich habe einen CMR-1000-Schalter den ich via FHEM steuern möchte - ohne Fernbedienung.
Ich kann also leider mit receive die Codes nicht auslesen - ich habe lediglich die beiden
Drehräder hinten am Schalter. Diese stehen auf J und auf 10.
Ich bekomme den Befehl fürs schalten einfach nicht hin. :o(
Steh wahrscheinlich auf der Leitung :o)
Grüße, Smeagel
Hm, das hilft aber nicht, Protokolle hin oder her , es muss ja möglich sein dem intertechno_switch zu sagen , das er seinen Zustand anzeigen soll...
Also welcher fhem-crack verrät mir wie es geht?
Mfg stadtkind
@smeagel
Tut mir leid ich habe keine Empfänger mit codier-rad....Aber such doch mal bei google nach "intertechno umrechnen"
Zitat von: stadtkind am 19 Oktober 2015, 00:33:32
Hallo, ich hoffe ich bin hier richtig..ansonsten bitte verschieben
Ich habe mir für einen intertechno itwr-3500 einen pilight_switch angelegt:
Define Lampe.nebeneingang pilight_switch intertechno_switch 1234 1
Funktioniert einwandfrei und schaltet wie er soll.
Aber leider zeigt er mir keine devstateicons an da steht immer nur "defined"...
Was muss ich tun um mir da den "schaltzustand" also ob ich auf an oder aus geschaltet habe anzeigen zu lassen? Is wahrscheinlich ne total blöde Anfängerfrage, wäre für jeden Tipp dankbar.
Mit freundlichen Grüßen stadtkind
Das liegt an den brandings in pilight. Das Antwortprotokoll ist nicht gleich dem Sendeprotokoll. Entweder man verwendet das Basisprotokoll (z.B. kaku_switch statt intertechno_switch) oder man muss die brandings mit dem Attribut brands in pilight_ctrl angeben.
vielen dank, das wars...
manchmal liest man etwas(commandref) und versteht es einfach nicht ;D
Hallo zusammen,
ich habe pilight laufen und das tut auch seinen Dienst. Nun will ich 4 steckdosen in fhem übernehmen, das gelingt mir leider nicht:
[...]
2015.10.28 12:22:08 2: Error messages while initializing FHEM: configfile: Unknown module pilight_ctrl Unknown module pilight_switch
2015.10.28 12:22:08 0: Server started with 10 defined entities (version $Id: fhem.pl 6913 2014-11-08 10:32:44Z rudolfkoenig $, os linux, user pi, pid 10166)
[...]
Gibt es hier eine step by step anleitung, oder eine mit kommentaren versehen sample fhem.cfg
Das wäre für Anfänger wie mich sehr hilfreich.
Ich finde es super was hier das Ergebnis der Community ist. Ein fettes Lob dafür.
Edit: Ich habe wohl gar nicht die richtigen Module. Gibt es hier einen Link wo ich die Module finde? Es scheint das diese hier mal im Thread verlinkt waren, dies aber gar nicht mehr für alle der Fall ist.
Gruß
J
Du musst, glaube ich, noch ein Teil von Perl installieren. Hatte damit auch Problem.
Schaue mal hier durch den thread.
Gesendet von meinem C6603 mit Tapatalk
Zitat von: stratege-0815 am 28 Oktober 2015, 13:19:30
[...]
2015.10.28 12:22:08 2: Error messages while initializing FHEM: configfile: Unknown module pilight_ctrl Unknown module pilight_switch
[...]
Edit: Ich habe wohl gar nicht die richtigen Module. Gibt es hier einen Link wo ich die Module finde? Es scheint das diese hier mal im Thread verlinkt waren, dies aber gar nicht mehr für alle der Fall ist.
Die Module sind in FHEM integriert. Wenn du
nicht direkt aus dem SVN gezogen hast, muss du auf jeden Fall ein update machen.
Es muss die Datei 10_pilight_ctrl.pm im FHEM Ordner geben!
Benötigt werden auf jeden Fall libjson-perl und libswitch-perl
Risiko
Dann klappt es auch mit pilight!
Hallo zusammen,
hier noch einen Erfolgsmeldung und Hinweis ggf. für andere. Das Update war der essentiell wichtige Teil.
Ich habe jetzt vier Pilight Schalter in FHEM.
So sind sie in der fhem.cfg angelegt:
#Pilight
define Subwoofer pilight silvercrest
attr Subwoofer systemcode 10
attr Subwoofer unitcode 29
define Drucker pilight silvercrest
attr Drucker systemcode 10
attr Drucker unitcode 13
define Lichterkette1 pilight silvercrest
attr Lichterkette1 systemcode 10
attr Lichterkette1 unitcode 5
define Lichterkette2 pilight silvercrest
attr Lichterkette2 systemcode 10
attr Lichterkette2 unitcode 21
Hier handelt es sich nicht um "meine" Module. Beitrag bitte entfernen!!!!
Hi Risiko,
ich bekomme im Log ziemlich viele Fehlermeldungen wie
2015.10.28 11:10:29 3: pilightCtrl: Unknown code PISWITCH,logilink_switch,981547,4,off, help me!
2015.10.28 11:10:29 3: pilightCtrl(Parse): unknown protocol -> ehome
2015.10.28 11:10:29 3: pilightCtrl: Unknown code PISWITCH,elro_800_contact,31,31,closed, help me!
2015.10.28 11:10:29 3: pilightCtrl: Unknown code PISWITCH,elro_800_switch,31,31,off, help me!
2015.10.28 11:10:29 3: pilightCtrl(Parse): unknown protocol -> daycom
2015.10.28 11:10:29 3: pilightCtrl(Parse): unknown protocol -> ev1527
Gibt es eine Möglichkeit diese los zu werden? :)
Hallo.
Attribut ignoreProtocol
Steht hier im Thread und in commandRef
Bitte um Hilfe für pilight_raw :-) Ich kriegs einfach nicht hin ...
define switch_Heizung_Wohnzimmer pilight_raw
attr switch_Heizung_Wohnzimmer onCode 330 4950 320 1010 320 1000 980 350 330 1010 310 1010 980 360 320 1010 320 1010 320 1010 970 370 970 360 320 1010 970 360 970 370 970 360 310 1030 950 370 960 380 310 1020 960 370 310 1020 960 370 320 1020 310 1010 310 1020 960 380 310 1010 960 370
attr switch_Heizung_Wohnzimmer offCode 320 4950 320 1010 320 1000 980 350 330 1000 320 1020 960 370 320 1020 310 1010 970 360 970 370 970 360 970 360 960 370 310 1030 310 1020 310 1020 960 360 970 370 310 1030 300 1020 310 1020 310 1030 310 1020 960 370 960 370 960 370 310 1010 970 370
funktioniert leider nicht. Auch mit Anführungszeichen geht es nicht :-\ Ein funktionierendes Schellscript anbei:
#!/bin/bash
line[0]="320 4950 330 1000 320 1010 970 360 320 1010 320 1000 980 370 310 1010 320 1020 310 1010 970 370 320 1010 970 360 970 360 310 1030 960 370 960 360 970 360 320 1020 320 1010 970 360 310 1020 310 1040 300 1020 310 1020 310 1010 970 370 960 370 310 1020"
line[1]="320 4950 320 1010 320 1000 980 350 330 1000 320 1020 960 370 320 1020 310 1010 970 360 970 370 970 360 970 360 960 370 310 1030 310 1020 310 1020 960 360 970 370 310 1030 300 1020 310 1020 310 1030 310 1020 960 370 960 370 960 370 310 1010 970 370"
line[2]="320 4950 970 360 970 360 970 360 310 1020 310 1010 970 370 970 360 970 360 970 360 320 1030 960 360 970 370 950 370 310 1040 950 370 960 370 310 1020 310 1030 960 370 960 370 300 1030 300 1030 960 370 960 370 310 1030 950 380 300 1020 960 370"
line[3]="310 4960 300 1020 300 1020 950 370 300 1020 300 1020 950 370 300 1020 950 370 300 1020 950 370 300 1020 950 370 950 370 300 1020 950 370 950 370 950 370 300 1020 300 1020 300 1020 300 1020 950 370 950 370 950 370 950 370 300 1020 950 370 300 1020"
line[4]="310 4960 300 1020 300 1020 950 370 300 1020 300 1020 950 370 300 1020 300 1020 300 1020 950 370 300 1020 950 370 950 370 950 370 300 1020 950 370 950 370 300 1020 300 1020 300 1020 950 370 950 370 300 1020 950 370 950 370 950 370 300 1020 950 370"
line[5]="310 4960 950 370 950 370 950 370 300 1020 300 1020 950 370 950 370 300 1020 950 370 300 1020 950 370 300 1020 300 1020 300 1020 300 1020 950 370 300 1020 300 1020 300 1020 950 370 300 1020 950 370 300 1020 950 370 300 1020 950 370 300 1020 950 370"
line[6]="310 4960 300 1020 950 370 950 370 300 1020 300 1020 950 370 300 1020 950 370 300 1020 950 370 950 370 950 370 300 1020 300 1020 950 370 950 370 950 370 950 370 950 370 300 1020 950 370 950 370 950 370 950 370 950 370 300 1020 950 370 300 1020"
line[7]="310 4960 300 1020 300 1020 950 370 300 1020 300 1020 950 370 950 370 300 1020 950 370 950 370 950 370 300 1020 300 1020 300 1020 950 370 950 370 300 1020 300 1020 300 1020 950 370 300 1020 300 1020 300 1020 300 1020 950 370 950 370 950 370 300 1020"
line[8]="310 4960 300 1020 300 1020 950 370 300 1020 300 1020 950 370 950 370 300 1020 300 1020 300 1020 300 1020 950 370 950 370 950 370 300 1020 300 1020 950 370 300 1020 950 370 300 1020 950 370 950 370 950 370 300 1020 950 370 300 1020 300 1020 950 370"
line[9]="310 4960 950 370 950 370 950 370 300 1020 300 1020 950 370 950 370 300 1020 950 370 300 1020 300 1020 950 370 300 1020 950 370 950 370 950 370 950 370 950 370 300 1020 950 370 300 1020 950 370 300 1020 300 1020 950 370 950 370 300 1020 950 370"
line[10]="310 4960 300 1020 950 370 950 370 300 1020 300 1020 950 370 300 1020 300 1020 300 1020 950 370 300 1020 950 370 300 1020 950 370 950 370 300 1020 950 370 950 370 300 1020 950 370 300 1020 950 370 950 370 950 370 300 1020 300 1020 950 370 300 1020"
line[11]="294 1029 294 1029 882 294 294 1029 294 1029 1029 294 294 1029 1029 294 294 1029 294 1029 294 1029 1029 294 1029 294 1029 294 294 1029 1029 294 1029 441 882 294 1029 294 1029 294 1029 294 294 1029 294 1029 294 1029 294 1029 1029 294 1029 294 294 1029 294 4998"
line[12]="294 1029 294 1029 1029 294 294 1029 294 1029 1029 294 1029 294 294 1029 882 441 882 441 1029 441 882 294 294 1029 1029 294 1029 441 882 441 882 441 882 441 294 1029 294 1029 1029 441 882 441 294 1029 882 441 294 1029 1029 294 294 1029 1029 294 294 4998"
line[13]="1029 294 1029 441 882 294 294 1029 294 1029 1029 294 294 1029 294 1029 294 1029 1029 294 1029 294 294 1029 1029 294 1029 441 294 1029 1029 294 1029 441 294 1029 1029 294 294 1029 294 1029 1029 441 1029 441 882 294 294 1029 882 294 294 1029 1029 294 294 4998"
line[14]="294 1029 882 294 1029 294 294 1029 294 1029 1029 294 1029 294 1029 294 294 1029 294 1029 1029 294 294 1029 1029 294 1029 441 1029 294 294 1029 294 1029 1029 294 294 1029 294 1029 1029 294 1029 441 1029 294 1029 294 294 1029 294 1029 1029 294 294 1029 294 4998"
pilight-send -p raw -c "${line[$1]}"
Wäre toll, wenn mir jemand mit dem fhem-Modul weiterhelfen kann - will nicht mehr den Umweg über Shellscript gehen.
Hallo ich habe Funk Rauchender von Flamingo fa20rf diese würde ich gerne auswerten.
Eigentlich möchte ich nur das wenn einer der Rauchender auslöst Fhem das Funk Signal mithört und darauf dann eine WhatsApp und Push Nachricht an mich versendet.
Kennt jemand das Protokoll bzw ist das mit pilight_Ctrl möglich?
Zitat von: master7811 am 02 November 2015, 19:35:23
Bitte um Hilfe für pilight_raw :-) Ich kriegs einfach nicht hin ...
Außer pilight_raw wird natürlich das Basismodul pilight_ctrl zuerst benötigt.
pilight_raw benötigt man nur, wenn die Hardware in pilight (noch) nicht mit einem Protokoll angesprochen werden kann.
Risiko
Zitat von: Tueftler1983 am 02 November 2015, 19:53:48
Hallo ich habe Funk Rauchender von Flamingo fa20rf diese würde ich gerne auswerten.
Eigentlich möchte ich nur das wenn einer der Rauchender auslöst Fhem das Funk Signal mithört und darauf dann eine WhatsApp und Push Nachricht an mich versendet.
Kennt jemand das Protokoll bzw ist das mit pilight_Ctrl möglich?
Grundvoraussetzung ist, dass die Hardware von pilight unterstützt wird. Am Besten hier mal schauen:
http://wiki.pilight.org/doku.php/protocols
Über alles Weitere können wir reden ;)
Risiko
Zitat von: Risiko am 03 November 2015, 19:34:07
Außer pilight_raw wird natürlich das Basismodul pilight_ctrl zuerst benötigt.
pilight_raw benötigt man nur, wenn die Hardware in pilight (noch) nicht mit einem Protokoll angesprochen werden kann.
Risiko
Ja, pilight funktioniert schon (in fhem) mit normalen switches - nur meine Flamingo switches werden noch nicht regulär unterstützt - von daher muss ich raw nutzen. Per shellscript klappt das auch, nur per pilight_raw nicht.
Gesendet von meinem E6553 mit Tapatalk
Hallo Leute !
Habe mir einen Funksensor für Temp/Feuchte gekauft.
Habe einen anoCUL. Dieser empfängt auch Daten und hatte einen CUL angelegt, jedoch scheint da was nicht in Ordnung zu sein.
Es werden keine Werte geschrieben, obwohl der Plot und der Rest angelegt wurde.
Hier ein Auszug aus dem LOG
2015.11.03 21:52:50 3: pilight: Unknown code PITEMP,tfa,207,temperature:21.27,humidity:48,battery:1, help me!
2015.11.03 21:52:50 3: pilight: Unknown code PITEMP,tfa,207,temperature:21.27,humidity:48,battery:1, help me!
2015.11.03 21:52:50 3: pilight: Unknown code PITEMP,tfa,207,temperature:21.27,humidity:48,battery:1, help me!
2015.11.03 21:52:50 3: pilight: Unknown code PITEMP,tfa,207,temperature:21.27,humidity:48,battery:1, help me!
2015.11.03 21:52:51 3: pilight: Unknown code PITEMP,tfa,207,temperature:21.27,humidity:48,battery:1, help me!
Habe auch mal mit Pilight-receive geschaut.
{
"message": {
"id": 207,
"temperature": 21.16,
"humidity": 48.00,
"battery": 1,
"channel": 3
},
"origin": "receiver",
"protocol": "tfa",
"uuid": "0000-b8-27-eb-6de740",
"repeats": 3
Jetzt meine Frage.
Wie kann ich den Sensor über den CUL einbinden, oder muss es über Pilight gehen ?
Und das ganze dann in eine Log datei schreiben !!
Danke !!!!!
greez@all
Sascha
Zitat von: master7811 am 03 November 2015, 20:28:35
Ja, pilight funktioniert schon (in fhem) mit normalen switches - nur meine Flamingo switches werden noch nicht regulär unterstützt - von daher muss ich raw nutzen. Per shellscript klappt das auch, nur per pilight_raw nicht.
Gesendet von meinem E6553 mit Tapatalk
Steht denn was im Log? Gegebenenfalls verbose von pilight_raw und pilight_ctrl auf 4 stellen. Die Codes im Script sind mit den Codes bei den Attributen von pilight_raw nicht identisch. Wieso hast du so viele Codes im Script - mehrere Schalter?
Zitat von: Risiko am 04 November 2015, 07:33:07
Steht denn was im Log? Gegebenenfalls verbose von pilight_raw und pilight_ctrl auf 4 stellen. Die Codes im Script sind mit den Codes bei den Attributen von pilight_raw nicht identisch. Wieso hast du so viele Codes im Script - mehrere Schalter?
Ok, verbose schau ich mir an. Bisher steht nur im log, dass der switch geschaltet wird - keine Fehler oder so. Es passiert aber nichts.
Ich habe für on und off jeweils ein eigenes Script - die gleiche übergebene id beim Aufruf führt in dem einen zum on-code, im anderen zum entsprechenden off-code - also ja, den off-code findet ihr nicht im Script :-)
Gesendet von meinem E6553 mit Tapatalk
Zitat von: sash.sc am 03 November 2015, 22:44:02
Jetzt meine Frage.
Wie kann ich den Sensor über den CUL einbinden, oder muss es über Pilight gehen ?
Und das ganze dann in eine Log datei schreiben !!
Danke !!!!!
greez@all
Sascha
Mit pilight geht es. Es fehlt wahrscheinlich das pilight_temp. Wenn das soweit geht, kann man ein separates Logfile für den Temperatursensor anlegen und plotten
Ob es mit dem CUL geht, kann ich nicht sagen. Dafür gibt es einen separaten Thread.
Danke für deine Antwort. Habe das mir pilight_temp hin bekommen. Eine separate log und Plot Datei erstellt. Funktioniert auch soweit. Auch eingestellt das nur geänderte Werte erfasst werden, da der Sensor im Minuten Takt am funken ist.
Wäre nicht schlecht, wenn man die Daten aus dem Haupt Log noch raus bekommt.
Hat du da eine Idee?
Danke im voraus.
Gesendet von meinem C6603 mit Tapatalk
Welche Daten? Schau dir mal Attribut ignoreProtocol an.
Werde ich mal machen.....
Gesendet von meinem C6603 mit Tapatalk
Zitat von: master7811 am 04 November 2015, 07:40:19
Ok, verbose schau ich mir an. Bisher steht nur im log, dass der switch geschaltet wird - keine Fehler oder so. Es passiert aber nichts.
Ich habe für on und off jeweils ein eigenes Script - die gleiche übergebene id beim Aufruf führt in dem einen zum on-code, im anderen zum entsprechenden off-code - also ja, den off-code findet ihr nicht im Script :-)
Gesendet von meinem E6553 mit Tapatalk
Verstehe ich leider nicht.
Du hast doch
attr switch_Heizung_Wohnzimmer offCode 320 4950 320 1010 320 1000 980 350 330 1000 320 1020 960 370 320 1020 310 1010 970 360 970 370 970 360 970 360 960 370 310 1030 310 1020 310 1020 960 360 970 370 310 1030 300 1020 310 1020 310 1030 310 1020 960 370 960 370 960 370 310 1010 970 370
definiert. Dieser Code steht doch im Script!!
line[1]="320 4950 320 1010 320 1000 980 350 330 1000 320 1020 960 370 320 1020 310 1010 970 360 970 370 970 360 970 360 960 370 310 1030 310 1020 310 1020 960 360 970 370 310 1030 300 1020 310 1020 310 1030 310 1020 960 370 960 370 960 370 310 1010 970 370"
Bedeutet der nun ON oder OFF? Denke da liegt der Fehler!
Risiko.
Egal ob ich ein oder ausschalte (Belegung wäre dann ja nur umgekehrt) die Steckdose tut nix
Gesendet von meinem E6553 mit Tapatalk
Ok. Dann schauen wir mal, was die Logs dann bringen.
Weiß so leider auch nicht weiter.
Hallo.
Wenn ich das richtig lese in diesem Forumbeitrag:
http://forum.pilight.org/Thread-Elro-Flamingo-FA20RF-Smoke-detector?page=6
Sollte es ein Protokoll namens: elro_fa20rf geben.
Oder habe ich da was falsch verstanden
Hi,
irgendwie bekomme ich das Modul nicht geladen. Von Commandozeile kann ich das aufrufen... aber FHEM mag es nicht. Ich hab per hand auf der Konsole service pilight start eingegeben um sicherzustellen dass pilight auch gestartet ist. danach in FHEM nochmal 'shutdown restart' und natürlich vorher 'update'.
Die Fernbedienung ist wie folgt definiert:
# ELRO Fernbedienung
define Fernbedienung pilight_ctrl localhost:5001
attr Fernbedienung brands elro
attr Fernbedienung icon access_keypad_2
Das FHEM.log gibt nach dem Neustart folgendes aus:
2015.11.09 17:30:24 1: usb create end
2015.11.09 17:30:24 0: Featurelevel: 5.6
2015.11.09 17:30:24 0: Server started with 16 defined entities (version $Id: fhem.pl 9809 2015-11-07 18:39:08Z rudolfkoenig $, os linux, user fhem, pid 606)
2015.11.09 17:30:24 1: PERL WARNING: Calling POSIX::isdigit() is deprecated at ./FHEM/10_pilight_ctrl.pm line 284.
2015.11.09 17:30:24 1: localhost:5001 disconnected, waiting to reappear (Fernbedienung)
2015.11.09 17:30:24 3: Opening Fernbedienung device localhost:5001
2015.11.09 17:30:24 3: Fernbedienung device opened
2015.11.09 17:30:36 1: localhost:5001 disconnected, waiting to reappear (Fernbedienung)
2015.11.09 17:31:39 3: Opening Fernbedienung device localhost:5001
2015.11.09 17:31:39 3: Fernbedienung device opened
2015.11.09 17:31:51 1: localhost:5001 disconnected, waiting to reappear (Fernbedienung)
Was mache ich falsch? Da fehlen doch sicher ein paar Schritte...
1. pilight installiert
2. Fernbedienung in FHEM definiert
3. ??? Muss ich die Fernbedienung die ich überwachen will, vorher in pilight anlegen (config.json)? Dort steht ja auch der Webport drin...? Die config.json sieht momentan so aus:
{
"devices": {},
"rules": {},
"gui": {},
"settings": {
"log-level": 6,
"pid-file": "/var/run/pilight.pid",
"log-file": "/var/log/pilight.log",
"webserver-enable": 1,
"webserver-root": "/usr/local/share/pilight/",
"webserver-http-port": 5001,
"webserver-cache": 1
},
"hardware": {
"433gpio": {
"sender": 0,
"receiver": 2
}
},
"registry": {
"pilight": {
"version": {
"current": "7.0"
}
}
}
}
Okay,
irgendwo hier im langen Beitrag die Lösung gefunden:
Ergänzung der config.json um
"port": 5000,
und dann noch die Fernbedienung in FHEM angepasst:
define Fernbedienung pilight_ctrl localhost:5001
Schon bekomme ich Code in den Eventmonitor!
2015-11-09 17:43:41 pilight_ctrl Fernbedienung rcv_raw: {"message":{"systemcode":6,"unitcode":31,"state":"on"},"origin":"receiver","protocol":"elro_400_switch","uuid":"0000-b8-27-eb-3647ad","repeats":6}
Der Port 5001 ist für das Webgui von pilight. Port 5000 für pilight_ctrl.
Gesendet von meinem C6603 mit Tapatalk
Zitat von: sash.sc am 09 November 2015, 18:01:19
Der Port 5001 ist für das Webgui von pilight. Port 5000 für pilight_ctrl.
Jupp. Hab ich auch mitbekommen. Schade dass der 5000er Port nicht schon automatisch in der Standard-Config steht und manuell eingetragen werden muss.
Kann/soll ich die Fernbedienung nun in der config.json festlegen und erhalte so ein kürzes FHEM.log. Ziel ist es auf Tastendruck der Fernbedienung in FHEM den Status eines devices anzupassen. Sollte ich das Device (aktuell als 00_GenShellSwitch definiert) in der pilight Logik anpassen. bringt doch eigentlich keine Vorteile oder?
Die config. Json musst du nur anpassen, wenn du das Webgui von pilight benutzt.
Gesendet von meinem C6603 mit Tapatalk
Zitat von: oberfragger am 09 November 2015, 18:07:24
Kann/soll ich die Fernbedienung nun in der config.json festlegen und erhalte so ein kürzes FHEM.log. Ziel ist es auf Tastendruck der Fernbedienung in FHEM den Status eines devices anzupassen. Sollte ich das Device (aktuell als 00_GenShellSwitch definiert) in der pilight Logik anpassen. bringt doch eigentlich keine Vorteile oder?
Empfehlenswert ist jetzt noch ein Switch mit pilight_switch anzulegen und in pilight_ctrl das Attribut ignoreProtocol zu setzen.
Hallo Risiko hast du mal geguckt wegen dem Protokoll elro_fa20rf ? Wäre schön die Rauch Melder integrieren zu können.
LG holger
Zitat von: sash.sc am 09 November 2015, 20:10:14
Die config. Json musst du nur anpassen, wenn du das Webgui von pilight benutzt.
Das Webgui ist mir eher unwichtig da ich FHEM nutzen will, aber ohne die manuelle Angabe des Ports in der config.json war es nicht möglich die Fernbedienung in FHEM zu empfangen. Nun funktioniert es wie gewünscht.
Zitat von: Risiko am 09 November 2015, 22:36:52
Empfehlenswert ist jetzt noch ein Switch mit pilight_switch anzulegen und in pilight_ctrl das Attribut ignoreProtocol zu setzen.
Ja, ich werde dann mal den Switch anlegen und vom 00_GenShellSwitch-Modul weggehen. Bringt ja nichts mit 5 verschiedenen Sachen rumzuhühnern. Wenn ich das richtig verstanden habe, ist der Switch jeweils meine fernbedienbare Steckdose oder irre ich?
Das ignoreProtocol soll ich setzen, damit die Fernbedienungen der Nachbarn nicht im Log auftauchen bzw. ignoriert werden...? Aktuell habe ich im Log folgende Einträge...
2015.11.10 10:45:34 3: Fernbedienung: Unknown code PITEMP,tfa,0,temperature:-67.77,humidity:0,battery:1, help me!Da funkt wohl jemand auf 433,95 Mhz.
Der Eintrag in deinem log mir dem tfa Sender kann auch ein "rauschen" sein, was von pilight entsprechend interpretiert wird wird. Habe auch identische Einträge im log.
Gesendet von meinem C6603 mit Tapatalk
Zitat von: sash.sc am 10 November 2015, 11:00:16
Der Eintrag in deinem log mir dem tfa Sender kann auch ein "rauschen" sein, was von pilight entsprechend interpretiert wird wird. Habe auch identische Einträge im log.
Ich bin hier schon am suchen... kann ich oder besser sollte ich nicht der Fernbedienung (pilight_ctrl) den spezifischen Gerätecode mitgeben? Oder geht das garnicht? Ich schau gerade die 25 Seiten durch.
So... das sieht ja schon alles mal super aus.
Beim Schalten mittel FHEM-Webfrontend wechseln sich nun die definierten Lichtschalter on/off ab. Das Webfrontend zeigt mir nun auch an, wenn ich diese Signal via Fernbedienung sende. 8)
:) Klasse Arbeit Risiko! Danke! :)
2 Fragen die noch offen sind. Wie bekomme ich die PERL:Warnung weg? Müsste hier vielleicht noch was am Modul gemacht werden
oder ist dieses ein lokales Problem? Wenn ich das richtig lese, wird der isdigit-Befehl nicht mehr genutzt??? Dieser taucht auch in den entsprechenden Zeilen der 10_pilight_ctrl.pm auf (das sind auch die einzigen Einträge damit.
Ergänzung: Ist veraltet. Quelle http://perldoc.perl.org/POSIX.html (http://perldoc.perl.org/POSIX.html)
Zitatisdigit
Deprecated function whose use raises a warning, and which is slated to be removed in a future Perl version. It is very similar to matching against qr/ ^ [[:digit:]]+ $ /x , which you should convert to use instead. The function is deprecated because 1) it doesn't handle UTF-8 encoded strings properly; and 2) it returns TRUE even if the input is the empty string. The function return is always based on the current locale, whereas using locale rules is optional with the regular expression, based on pragmas in effect and pattern modifiers (see Character set modifiers in perlre and Which character set modifier is in effect? in perlre).
The function returns TRUE if the input string is empty, or if the corresponding C function returns TRUE for every byte in the string.
You may want to use the /\d/ construct instead.
Leider bin ich (im programmieren) etwas zu schlecht um dieses anzupassen. Vielleicht ist es ja nur ein Tausch der Funktionen...?!? :-X
2015.11.10 13:26:14 1: PERL WARNING: Calling POSIX::isdigit() is deprecated at ./FHEM/10_pilight_ctrl.pm line 284.
2015.11.10 13:26:24 1: PERL WARNING: Calling POSIX::isdigit() is deprecated at ./FHEM/10_pilight_ctrl.pm line 395.
2015.11.10 13:26:24 1: PERL WARNING: Calling POSIX::isdigit() is deprecated at ./FHEM/10_pilight_ctrl.pm line 396.Die zweite Frage- wie mache ich mein Log etwas sauberer...? Ich benutze 2 verschiedene Fernbedienungen. Hier mal die Definition der beiden.
# ELRO Fernbedienung Wohnzimmer
define Wohnzimmer_Fernbedienung pilight_ctrl localhost:5000
attr Wohnzimmer_Fernbedienung brands elro
attr Wohnzimmer_Fernbedienung group Allgemein
attr Wohnzimmer_Fernbedienung icon access_keypad_2
attr Wohnzimmer_Fernbedienung ignoreProtocol arctech_screen_old:*
attr Wohnzimmer_Fernbedienung room Wohnzimmer
# IT Fernbedienung Schlafzimmer
define Schlafzimmer_Fernbedienung pilight_ctrl localhost:5000
attr Schlafzimmer_Fernbedienung brands elro
attr Schlafzimmer_Fernbedienung group Allgemein
attr Schlafzimmer_Fernbedienung icon access_keypad_2
attr Schlafzimmer_Fernbedienung ignoreProtocol ev1527:*
attr Schlafzimmer_Fernbedienung room SchlafzimmerAls Ausgabe erhalte ich im Log immer 5 Einträge.
2015.11.10 13:34:36 3: Schlafzimmer_Fernbedienung: Unknown code PISWITCH,pollin,1,8,on, help me!
2015.11.10 13:34:36 3: Wohnzimmer_Fernbedienung: Unknown code PISWITCH,elro_800_contact,1,8,opened, help me!
2015.11.10 13:34:36 3: Wohnzimmer_Fernbedienung(Parse): unknown protocol -> ev1527
2015.11.10 13:34:36 3: Schlafzimmer_Fernbedienung: Unknown code PISWITCH,pollin,1,8,on, help me!
2015.11.10 13:34:36 3: Wohnzimmer_Fernbedienung(Parse): unknown protocol -> ev1527
2015.11.10 13:34:36 3: Schlafzimmer_Fernbedienung: Unknown code PISWITCH,pollin,1,8,on, help me!
2015.11.10 13:34:36 3: Wohnzimmer_Fernbedienung(Parse): unknown protocol -> ev1527
Hallo oberfragger,
isdigit habe ich ersetzt. Ab morgen per Update.
Zum zweiten Teil (da hast du leider so Einiges falsch oder gar nicht verstanden, Sorry):
1. Es wird nur einmal das Device pilight_ctrl zur Kommunikation mit pilight benötigt!!!!
2. Pro Schalter, Dose, Taste der Fernbedienung, etc. (einzelne Geräte) benötigt man ein pilight_switch
3. Wenn alle Protokolle und ID's bekannt sind, kann man in pilight_ctrl ignoreProtocol auf "*" setzen.
Also ungefähr so:
define pilight pilight_ctrl localhost:5000
attr pilight ignoreProtocol *
define Schalter_Schlafzimmer pilight_switch pollin 1 8
define Schalter_Wohnzimmer pilight_switch elro_400_switch 6 31
Hoffe ich habe die Protokolle und ID's so richtig aus deinen Beiträgen heraus gesucht.
Risiko
Hallo Risiko,
vielen Dank für die schnelle Info und das schnelle Update.
1. Ok, verstanden. Habe da 2 Fernbedienungen vom gleichen Typ. Klar kann ich nun eine weglassen...
2. Jupp auch klar.
3. Werde ich mal gleich testen.
Danke für den Service dass Du sogar die Schalterdefinition gepostet hast! Das ist zu freundlich von Dir. War nicht meine Erwartung. Danke. -> hatte ich auch schon selbstständig hinbekommen yay! Sind beide Male Elro 800.
define Wohnzimmer_A pilight_switch elro_800_switch 1 1
define Schlafzimmer_A pilight_switch elro_800_switch 19 1
Hab das alles vorbereitet, zuhause angeschlossen. Bin begeistert. Nun funktioniert es so wie es soll (also das Lämpchen wird bei Benutzung der FB auch umgeschaltet). Super. Systemlast (im pilight webfrontend abgelesen) ist nie über 20%.
Ansonsten- diese Chinadinger haben ja eine miserable Empfangsleistung. Hatte das gelesen...sollte mal überlegen ob ich da wirklich die 3 Euro für die SMA-Buchse ausgebe um da eine bessere Antenne anzulöten.
Hallo zusammen.
Ich habe einen Sender mit pilight an laufen, der bis zu 12V= verträgt. Einen gemeinsamen Massepunkt für die externe Spannungsversorgung und dem Sender. Den braucht man, da sonst der Sender nix sendet. Peinlichst darauf achten das der externe pluspol nur an den entsprechenden Anschluss an den Sender kommt.
Bei mir hatte es denn Effekt, dass ich durch 2 Wände mehr gekommen bin. Laut den technischen Daten hat der Sender bei 12v eine Leistung von bis zu 34mW. Da kommt man schon ein bisschen weiter
Habe einen Sender mit 9V Block im Moment am laufen.
Werde mal den Typ raus suchen.
Nachtrag : hier ist der Sender bis zu 12V Betriebsspannung
(http://images.tapatalk-cdn.com/15/11/12/9fbcc96a142a41d43e7c9be4608c12e1.jpg)
(http://images.tapatalk-cdn.com/15/11/12/03a345fa28e68a0eee5117000df0d8bb.jpg)
(http://images.tapatalk-cdn.com/15/11/12/8a1789b3a76aa75125d1473d877019bb.jpg)
(http://images.tapatalk-cdn.com/15/11/12/b205bb9ffe404a134fd78cd395d0061a.jpg)(http://images.tapatalk-cdn.com/15/11/12/7b583d541c6f498414860f642666d596.jpg)
Hallo nochmal also über pilight-receive bekomme ich nix an Daten rein wenn ich den Test Knopf drücke.
Über pilight_raw bekomme ich volgendes rein:
433gpio: 5365 -#: 1
433gpio: 1385 792 2962 508 1470 732 1440 786 1413 736 1504 671 2834 719 1465 746 1453 753 2828 766 1421 727 2827 665 2811 733 2817 793 1394 1068 1169 724 2772 737 2808 734 2830 769 1418 768 1456 735 1438 725 2786 776 17552 -#: 47
433gpio: 8094 -#: 1
433gpio: 1751 2754 738 1495 681 2839 797 1391 693 1523 700 1489 1364 1522 2874 680 1476 736 1459 726 2889 742 1408 673 2869 674 2834 750 2797 702 1547 699 1460 694 2985 558 2813 745 2786 717 1504 848 1344 784 1393 747 2731 753 17652 -#: 49
433gpio: 8069 -#: 1
433gpio: 1795 2707 702 1551 753 2711 728 1805 443 1431 762 1711 448 1465 758 2777 730 1502 723 1463 703 2854 688 1478 747 2790 740 2831 724 2778 726 1506 694 1512 712 2787 729 2839 745 2810 683 1503 696 1505 743 1425 758 2754 708 17841 -#: 50
433gpio: 8055 -#: 1
433gpio: 1743 2735 723 1516 699 2803 721 1537 698 1448 758 1491 691 1447 759 2837 673 1500 727 1439 722 2847 698 1507 714 2788 730 2835 748 2813 684 1492 706 1503 739 2760 740 2829 735 2816 692 1498 697 1508 695 1466 765 2744 717 17281 -#: 50
433gpio: 8090 -#: 1
433gpio: 1668 2794 763 1438 992 2602 736 1437 699 1490 703 1468 733 1480 744 2777 803 1436 690 1506 687 2849 743 1422 743 2841 734 2791 699 2836 705 1499 732 1445 733 2832 710 2819 706 2854 686 1472 755 1440 733 1501 685 2774 714 17264 -#: 50
433gpio: 8089 -#: 1
433gpio: 1729 2788 714 1552 679 2828 671 1565 630 1486 793 1414 697 1509 723 2800 707 1506 734 1433 743 2839 680 1517 714 2828 680 2849 724 2786 756 1453 704 1488 745 2784 726 2843 712 2802 756 1439 726 1558 662 1428 735 2778 699 17318 -#: 50
433gpio: 8086 -#: 1
433gpio: 1657 2822 716 1472 718 2829 754 1593 603 1449 733 1438 727 1487 742 2788 765 1491 659 1503 696 2821 730 1464 760 2799 756 2784 706 2893 661 1462 729 1467 768 2775 761 2776 725 2869 677 1461 733 1468 762 1479 678 2817 706 17292 -#: 50
433gpio: 8135 -#: 1
433gpio: 1652 2809 758 1443 745 2835 668 1509 689 1493 688 1503 725 1446 719 2860 682 1527 700 1456 759 2820 695 1508 798 2700 723 2873 668 2813 736 1470 713 1766 509 2736 732 2849 691 2807 733 1467 755 1506 731 1428 706 2783 691 153097 -#: 50
433gpio: 17745 -#: 1
433gpio: 1655 2558 1025 153 2364 308 2463 552 176 445 5003 235 290 5450 -#: 14
433gpio: 2460 8664 -#: 2
433gpio: 1851 1067 572 187 6323 -#: 5
433gpio: 4402 832 1356 790 2847 699 1401 805 1393 776 1454 753 1463 771 2743 736 1478 719 1480 797 2722 750 5037 703 2944 570 2804 760 1434 745 1456 723 2842 713 2837 688 2834 744 1440 749 1512 658 1483 713 2806 722 17227 -#: 47
433gpio: 8044 -#: 1
433gpio: 1711 2808 677 1526 1017 2504 698 1520 693 1493 756 1427 700 1480 748 2795 787 1461 677 1497 691 2827 713 1507 739 2779 748 2805 705 2803 733 1475 723 1500 727 2781 760 2810 714 2848 677 1495 699 1550 679 1440 759 2801 648 17264 -#: 50
433gpio: 8107 -#: 1
433gpio: 4461 722 1432 772 2866 1028 1098 688 1471 752 1448 748 1475 698 2856 720 1451 710 1508 724 2796 740 1477 691 2833 738 2783 726 2865 709 1446 751 1485 690 2886 689 2780 752 2828 694 1470 797 1428 692 1523 672 2784 690 181170 -#: 49
433gpio: 3323 8639 -#: 2
433gpio: 1944 1157 212 7360 -#: 4
433gpio: 3161 414 149 259 1250 364 4241 4827 308 953 249 408 150 261 258 915 533 7469 -#: 18
433gpio: 2409 6314 -#: 2
433gpio: 1624 255 3185 376 252 341 237 283 1317 413 485 1777 349 310 531 299
Vielleicht hilft es ja weiter ich kann mit den raw code nix anfangen
Hallo Tueftler1983
Das Protokoll "elro_fa20rf" scheint noch nicht offiziell in pilight enthalten zu sein.
Daher zeigt pilight-receive sehr wahrscheinlich auch nichts an.
Wenn die Codes richtig sind (also nicht nur Rauschen), dann kannst du mit dem FHEM-Modul pilight_raw einen Schalter zum Senden der Codes verwenden.
Die Codes sollten natürlich mit pilight-send -p raw -c <code> funktionieren, sonnst wird es mit FHEM auch nichts.
Mit dem FHEM-Modul pilight_raw kann man nur von FHEM Senden (pilight-receive empfängt ja nichts!!!)
Hilfe!
pilight funktioniert auf meinem Raspi und fhem geht.
Bei Eingabe von "define myctrl pilight_ctrl localhost:5000" erscheint es bei Unsorted - aber mit disconnected. "set myctrl reset" führt zu keiner Veränderung.
Wenn ich das mit dem port 5001 definiere, erscheint open - aber nur kurz.
5001 ist ja wohl für webgui von pilight, was ja auch geht.
Muss ich in json.conf was eintragen, wenn ich mit fhem darauf zugreifen will?
Danke
Ja. Steht aber hier auch im Beitrag weiter vorne.
Gesendet von meinem C6603 mit Tapatalk
Hallo zusammen,
bin neu in der Materie und komme irgend wie nicht weiter nach Eingabe von:
#Pilight
define mytest plight_ctrl localhost:5000 7.0
attr mytest brands elro
attr mytest room pilight
define Reserve_oben pilight_switch elro_800_switch 22 4
attr Reserve_oben room pilight
kommt als Fehlermeldung:
Unknown module plight_ctrl Please define mytest first Please define mytest first Cannot load module pilight_switch Please define Reserve_oben first
Module habe ich über update geholt.
mit Modul 98_pilight konnte ich schon Intertechno schalten wollte jetzt aber auch elrostecker schalten,
daher wollte ich umsteigen.
Alle alten Einträge zu pilight habe ich in der fhem.cfg gelöscht.
Muß noch irgendetwas in pilight und auf dem Pi installiert werden?
Gruß
Oha!
Dank google gefunden, dass er "plight" nicht mochte. Bitte noch das "i" in pilight_ctrl ergänzen!
Zitat von: Beagel am 16 November 2015, 23:52:13
#Pilight
define mytest pilight_ctrl localhost:5000 7.0
attr mytest brands elro
attr mytest room pilight
define Reserve_oben pilight_switch elro_800_switch 22 4
attr Reserve_oben room pilight
kommt als Fehlermeldung:
Unknown module pilight_ctrl
snip!
-> die API kannste weglassen. Und dann wie von Risiko empfohlen noch
attr mytest ignoreProtocol *ergänzen. Dann wird das Log nicht so zugemüllt.
Danke, war wohl etwas spät hab den Wald vor lauter Bäumen nicht mehr gesehen :)
die Autokorrektur schlägt immer wieder bei Eingabe von pilight zu, muss ich im Auge behalten. ;D
Jetzt klappt es, es werden Elro und auch Intertechno Funksteckdosen geschaltet, allerdings ändert sich das Lampen icon nicht.
update: Lampenicon ändert sich jetzt beim schalten, allerdings muß der Schaltbefehl mehrmals hintereinander gedrückt werden, kann man das irgend wo einstellen?
Gruß
Steht in fhem.cfg auch das ctrl vor den switches? Poste sonst mal die Definition (wenn Du auf den Namen der Devices klickst) der Fernbedienung (pilight_ctrl) und eines Switches (pilight_switch).
Hallo hier ein Auszug aus der fhem.cfg
#-----------pilight-----------------
define pilight pilight_ctrl localhost:5000
attr pilight brands arctech:kaku
attr pilight ignoreProtocol *
attr pilight room pilight
define Reserve_oben pilight_switch elro_800_switch 22 4
attr Reserve_oben room Funksteckdosen
define Reserve_oben_an at *{sunrise(0,"06:30","08:30")} set Reserve_oben on
define Stehlampe_oben pilight_switch elro_800_switch 22 1
attr Stehlampe_oben room Funksteckdosen
define Fernseher_oben pilight_switch elro_800_switch 22 2
attr Fernseher_oben room Funksteckdosen
define Wohnzimmer_Rechts pilight_switch kaku_switch 11196830 0
attr Wohnzimmer_Rechts room Funksteckdosen
define Wohnzimmer_Links pilight_switch kaku_switch 11196830 1
attr Wohnzimmer_Links room Funksteckdosen
define Sideboard pilight_switch kaku_switch 11196830 2
attr Sideboard room Funksteckdosen
define Sideboard_an at *{sunset(0,"16:30","22:30")} set Sideboard on
define Buero_oben pilight_temp ds18b20 041590217bff
attr Buero_oben room Heizung
pilight_ctrl:
API 6.0
DEF localhost:5000
DeviceName localhost:5000
FD 12
NAME pilight
NR 70
NTFY_ORDER 50-pilight
PARTIAL RETRY_INTERVAL 60
STATE connected
TYPE pilight_ctrl
Readings
rcv_raw empty 2015-11-18 11:12:02
state connected 2015-11-18 11:12:02
Attributes
brands arctech:kaku deleteattr
ignoreProtocol * deleteattr
room pilight deleteattr
pilight_switch:
DEF kaku_switch 11196830 2
ID 11196830
IODev pilight
NAME Sideboard
NR 77
PROTOCOL kaku_switch
STATE off
TYPE pilight_switch
UNIT 2
hoffe das bei copy/paste nicht weggelassen wurde :D
Also ich bin raus. Normalerweise sollte das Icon umschalten. Das sieht bei mir nicht viel anders aus- außer dass ich noch eine IODev und einen Messagecount ahbe. Das hängt glaube cih eher damit zusammen dass ich parallel den Empfänger dran habe.
Ändert sich denn der "State" der Switches wenn Du anschaltest? Weil schalten geht ja bei Dir via Weboberfläche- nur das Icon wechselt nicht mit...?
"update" und reboot hast Du auch mal in der letzten Zeit gemacht?
Kannst Du ggf. mal diese "defines" auskommentieren und überprüfen was passiert...?define Reserve_oben_an at *{sunrise(0,"06:30","08:30")} set Reserve_oben on
Anmerkung (ist wirklich nicht im Besserwissermodus gemeint):
Momentan sind die Namen ja selbsterklärend... aber für später (wenn Du viele Devices angeschlossen hast- lasse zwischen den einzelnen Sensoren/ Aktoren etc. eine Zeile frei und besser noch...kommentier die nächste Zeile. Dann lässt sich das auch für andere etwas besser lesen ::). So in dieser Art:# ELRO Fernbedienung Wohnzimmer
define Fernbedienung pilight_ctrl localhost:5000
attr Fernbedienung brands elro
attr Fernbedienung icon it_remote
attr Fernbedienung ignoreProtocol *
# Schlafzimmer Steckdose A
define Schlafzimmer_A pilight_switch elro_800_switch 19 1
Ansonsten- schau mal hier rein. Hier liegt anscheinend das gleiche Problem (zumindest gleiche Auswirkungen) vor.
http://forum.fhem.de/index.php?topic=17913.0 (http://forum.fhem.de/index.php?topic=17913.0)
Erst mal Danke :)
im Moment funktioniert es, Icon und State werden umgeschaltet, hatte mehrfach Neugestartet und auch update durch geführt, hab dann wie aus dem verlinkten Thread ein update force durch geführt, Neustart
und jetzt gehts.
ZitatAnmerkung (ist wirklich nicht im Besserwissermodus gemeint):
Ne schon gut, hab normaler Weisse immer eine Zuordnung und zwischen den einzelnen Bereichen leerzeilen, finde ich auch übersichtlicher, hatte die nur rausgenommen um zu testen ob das eine Auswirkung auf das Schaltverhalten hat.
Gruß Beagel
Zu früh gefreut :( heute geht es wieder nicht mehr, Icon und State ändern sich nicht obwohl die Schaltbefehle aus geführt werden. Es funktioniert anscheinend nur nach einem Shutdown restart von Fhem. Fehler suche geht weiter.
Das Problem habe ich auch. Ursache aber noch nicht feststellen können. mir scheint es so, wenn man zuviel im laufenden Betrieb rumspielt, Fehler etc. im Log produziert, ist halt ein 'shutdown restart' notwendig.
Habe da mal eine Fage zu dem ignoreProtocol.
Habe versucht folgende Daten auszuschliessen. Funktioniert nur nicht so wie ich es will.
Folgende möchte ich ausschliessen.
2015-11-26 20:00:00 pilight_ctrl pilight rcv_raw: {"message":{"id":0,"temperature":-67.77,"humidity":0.00,"battery":1,"channel":1},"origin":"receiver","protocol":"tfa","uuid":"0000-b8-27-eb-6de740","repeats":1}
2015-11-26 20:00:00 pilight_ctrl pilight UNKNOWNCODE PITEMP,tfa,0,temperature:-67.77,humidity:0,battery:1
2015-11-26 19:59:50 pilight_ctrl pilight rcv_raw: {"message":{"id":6,"unit":5,"state":"off"},"origin":"receiver","protocol":"conrad_rsl_switch","uuid":"0000-b8-27-eb-6de740","repeats":1}
2015-11-26 19:59:50 pilight_ctrl pilight UNKNOWNCODE PISWITCH,conrad_rsl_switch,6,5,off
mit folgender Definition
define pilight pilight_ctrl localhost:5000
attr pilight ignoreProtocol tfa*
attr pilight ignoreProtocol conrad_rsl_switch
Hat da jemand einen guten Ansatz zur Lösung ?
Danke !
greez
Sascha
Hallo sash.sc
Sollte so gehen
attr pilight ignoreProtocol tfa:*,conrad_rsl_switch:*
Also die beiden Protokolle (tfa, conrad_rsl_switch) komplett ignorieren.
Oder so
attr pilight ignoreProtocol tfa:0,conrad_rsl_switch:6
Genau die Beiden.
Zitat von: Risiko am 26 November 2015, 21:19:44
Hallo sash.sc
Sollte so gehen
attr pilight ignoreProtocol tfa:*,conrad_rsl_switch:*
Also die beiden Protokolle (tfa, conrad_rsl_switch) komplett ignorieren.
Oder so
attr pilight ignoreProtocol tfa:0,conrad_rsl_switch:6
Genau die Beiden.
Besten Dank
Gesendet von meinem C6603 mit Tapatalk
habe da noch eine Frage zu corrTemp.
Habe festgestellt, das die Korrectur der empfangenene Temp in % geht (z.b corrTemp 1.1 -> +10%; corrTemnp 1.2 -> +20%).
Besteht die Möglichkeit dies mit einem Offset (gemessenen Temp +2°C) zu realisieren anstatt in %, und auch ein "offset" in den negativen bereich?
Z.B. gem. temp -1,5 °C um die Streung von den Sensoren in den griff zu bekommen !
greez
Sascha
Hallo.
Das hat nichts mit Prozent zu tun. Es ist einfach ein Faktor, mit dem der Wert von pilight multipliziert wird.
Ein Offset gibt es aktuell nicht. Müsste erweitert werden.
Evtl. kann man das auch in pilight machen (habe ich selbst nicht getestet).
Siehe "temperature-offset"
http://wiki.pilight.org/doku.php/alecto_wsd17_v7_0
ZitatDas hat nichts mit Prozent zu tun. Es ist einfach ein Faktor, mit dem der Wert von pilight multipliziert wird.
Ein Offset gibt es aktuell nicht. Müsste erweitert werden.
Evtl. kann man das auch in pilight machen (habe ich selbst nicht getestet).
Siehe "temperature-offset"
http://wiki.pilight.org/doku.php/alecto_wsd17_v7_0
So wie ich das verstehe, bezieht sich der Offset auf die Anzeige in der Pilight GUI (Also im Webinterface von Pilight), welches wir ja in FHEM nicht nutzen.
Ich denke, dass mit dem Offset in pilight Modul ist keine schlechte Idee!
Gesendet von meinem C6603 mit Tapatalk
Hallo.
pilight_temp hat ab morgen zwei neue Attribute "offsetTemp" und "offsetHumidity" um den Wert von pilight mit einem Offset zu versehen.
Folgende Formel wird für Temperatur angewendet: temp = corrTemp * pilight_temp + offsetTemp
Risiko
Danke für die schnelle Umsetzung!
Gesendet von meinem C6603 mit Tapatalk
Ich weiss nicht ob mein anliegen hier richtig gepostet ist.
Ich empfange Daten von einem Temp.sensor überp pilight. Jetzt habe ich festgestellt, dass der Sensor manchmal "Ausbrüche" der Werte hat, sprich extreme Abweichung. Z.b. von 22°C auf -10°C. Das gleiche passiert mit den Feuchtigkeitswerten von dem gleichen Sensor.
Gibt es die Möglichkeit, die Empfangenen Daten zu "beobachten" und zu "filtern"?
Meine Vorstellung wäre, dass die Daten überprüft werden auf eine Abweichung größer z.B. +/- 4°C (Abweichung frei einstellbar).
Sollte die Abweichung größer sein, bezogen auf den letzten Wert, dann soll der "Ausreisser" nicht ins Log geschrieben werden.
So bleibt mir eine manuelle Nachbearbeitung des LOG´s erspart ! ;-)
Gruß
Sascha
Hallo Sascha,
das liegt sehr wahrscheinlich am Rauschen der "billigen" Empfänger. Habe\Hatte das Problem auch und habe sogar über eine Ähnliche Lösung nachgedacht aber noch nicht umgesetzt.
Allein mit einem Schwellwert für die Differenz alter und neuer Wert wird man sehr wahrscheinlich nicht glücklich. Mann muss auf jeden Fall die Zeitdifferenz mit betrachten.
Ich konnte das Problem reduzieren, indem ich in pilight nicht GPIO sondern lirc als Hardwaremodul verwende.
http://forum.fhem.de/index.php/topic,34632.msg287771/topicseen.html#msg287771
Damit reduziert sich aber leider die Empfangsleistung.
Da wir jetzt schon mind. zwei mit dem Problem sind, würde ich die Idee wahrscheinlich wieder aufgreifen.
Auf der pilight Homepage gibt es auch den Hinweis mit dem "rauschen". Daher habe ich auch eine permanente grundlast des pi von ca.20%. Ich überlege, ob ich mir den nano, wie der signalduino, nur von pilight zusammen baue. Sind ja nur zwei Drähte ändern und die entsprechende Firmware drauf bügeln. Dadurch dürfte sich die Situation von pilight verbessern. Vorteil ist, dort ist schon eine filterfunktion eingebaut,die das rauschen unterdrücken dürfte.
Mal schauen...........
Gruß
Sascha
Zitat von: sash.sc am 06 Dezember 2015, 19:54:39
Auf der pilight Homepage gibt es auch den Hinweis mit dem "rauschen". Daher habe ich auch eine permanente grundlast des pi von ca.20%. Ich überlege, ob ich mir den nano, wie der signalduino, nur von pilight zusammen baue. Sind ja nur zwei Drähte ändern und die entsprechende Firmware drauf bügeln. Dadurch dürfte sich die Situation von pilight verbessern. Vorteil ist, dort ist schon eine filterfunktion eingebaut,die das rauschen unterdrücken dürfte.
Mal schauen...........
Gruß
Sascha
Hast du den 433Mhz Empfänger direkt am RaspberryPI? Dann nimm den pilight Bandpassfilter der funktioniert super habe ihn selber auch drin
Habe den Empfänger direkt am gpio Port hängen. Werde wohl dem pilight nano bauen. Mal schauen was dann los ist
Gesendet von meinem C6603 mit Tapatalk
Zum Rauschen: direkt am GPIO war die Situation bei mir ziemlich sinnlos: mal Signal, mal nicht und ziemlich viel dazwischen. Mit dem Bandpass Filter wurde es erheblich besser, jetzt mit dem dem Nano klappt der Empfang hervorragend. Vorausgesetzt ich bringe den Empfänger einige cm vom Raspberry PI weg.
Welchen nano hast du denn mit pilight an laufen?
Gesendet von meinem C6603 mit Tapatalk
Hallo, ich bin komplett neu in der Welt von Fhem und konsorten. Ich lese hier viel mit und will mir nach und nach was aufbauen. Jetzt bin ich beim rauskramen der Weihnachtsdeko, bei der auch aldi funksteckdosen dabei sind für die ganzen Lichterketten, über pilight gestossen. Da ich aber letztlich eher zu fhem gehen will wollte ich das steuern solcher Funksteckdosen mit Fhem machen. Sehe ich es richtig, das man mit FHEM die ganzen billigfunksteckdosen nicht direkt steuern kann, mit pilight aber sehr wohl? Das auch noch kostengünstig über diesen GPIO Funksender/Empfänger? Und das es dann mit den hier vorgestellten modulen möglich ist die Funksteckdosen mit FHEM über pilight zu steuern? Muss ich dazu die Funksteckdosen in Pilight und in FHEM konfigurieren, oder reicht es diese in FHEM zu konfigurieren und pilight wird quasi nur zum ausführen der befehle benutzt?
Du kannst die "billig" Steckdosen nur über pilight, pilight und fhem, oder nur fhem steuern.
Für fhem brauchst du den nano cul oder Signalduino.
Mit pilight geht es auch über fhem. Musst du mal hier im thread schauen.
Gesendet von meinem C6603 mit Tapatalk
ZitatHallo, ich bin komplett neu in der Welt von Fhem und konsorten. Ich lese hier viel mit und will mir nach und nach was aufbauen. Jetzt bin ich beim rauskramen der Weihnachtsdeko, bei der auch aldi funksteckdosen dabei sind für die ganzen Lichterketten, über pilight gestossen. Da ich aber letztlich eher zu fhem gehen will wollte ich das steuern solcher Funksteckdosen mit Fhem machen. Sehe ich es richtig, das man mit FHEM die ganzen billigfunksteckdosen nicht direkt steuern kann, mit pilight aber sehr wohl? Das auch noch kostengünstig über diesen GPIO Funksender/Empfänger? Und das es dann mit den hier vorgestellten modulen möglich ist die Funksteckdosen mit FHEM über pilight zu steuern? Muss ich dazu die Funksteckdosen in Pilight und in FHEM konfigurieren, oder reicht es diese in FHEM zu konfigurieren und pilight wird quasi nur zum ausführen der befehle benutzt?
Also ich schalte aktuell meine Steckdosen aus dem Bauhaus nicht über pilight sondern über wiringPi. Ich habe die Anleitung verwendet um das auf dem Pi einzurichten.
http://www.gtkdb.de/index_36_2261.html
Du kannst diese anschließend über die Konsole oder auch über FHEM so schalten.
define Lampe_PC dummy
attr Lampe_PC room Lichtsteuerung
attr Lampe_PC setList on off
define off_Lampe_PC notify Lampe_PC:off {system("/usr/local/bin/send433 11000 4 0 &")}
define on_Lampe_PC notify Lampe_PC:on { system("/usr/local/bin/send433 11000 4 1 &")}
Hallo.
Hier im Thread geht es um die FHEM Module zu Anbindung von pilight und nicht um andere Lösungen!!!
Danke.
Hallo Zusammen,
ich habe schon einige Zeit die Pilight Module im Einsatz. Ich nutze es in Verbindung mit einem Pilight Arduino Nano USB.
Jetzt meine Frage:
Ich habe mehrere Temperatursensoren, welche leider nicht alle durch das Empfänger Modul empfangen werden, wegen der Reichweite.
Ich habe einen 2 Raspberry mit pilight+Nano USB Hardware ausgestattet. Das eigentliche Pilight baut ja adhoc Verbindungen zwischen 2 Pilights auf. Meine Hoffnung war, das ich dadurch die Reichweite vergrößern könnte. Leider werden die empfangen Daten vom 2 Pilight nicht angezeigt im FHEM Modul.
Mein nächster Gedanke war eine 2. Instanz in FHEM (also myctrl_2) einzurichten. Hier würde ich dann die IP +Port des anderen Raspberrys eintragen auf dem eine pilight Instanz läuft. Aber leider habe ich keine Ahnung wie ich dann das myctrl_2 ansprechen kann.
Eine Definition eines Gerätes in FHEM läßt es ja nicht zu das IODev auszuwählen? (zumindest habe ich das in pilight_temp nicht gefunden?).
Meine Vorstellung wäre ein Attribut im Device wo man das IODevice setzen kann? Oder beim definieren sage ich ihm, benutze myctrl_2?
Meine augenblickliche Definition des TempSensors sieht so aus:
define myctrl pilight_ctrl localhost:5000
attr myctrl room Test
define AUSSENTEMP_1 pilight_temp teknihall 204
attr AUSSENTEMP_1 alias Aussentemperatur
attr AUSSENTEMP_1 group Temperaturen,Wohnzimmer
attr AUSSENTEMP_1 icon temp_temperature
attr AUSSENTEMP_1 room Test
für die 2 Instant auf dem anderen Raspberry würde ich jetzt
define myctrl_2 pilight_ctrl 192.168.178.23:5000
attr myctrl_2 room Test
Einrichten
Dann würde ich gern dem Sensor sagen wollen, das er dieses IODevice nehmen soll...
Ich hoffe ich habe das einigermaßen verständlich ausgedrückt?
Gruß
Jens
Du kannst deinem 2.ten Pilight einen anderen Port als 5000 zuweisen z.B. 5001 dann gibst du im Fhem beim pilight_ctrl statt Port 5000 einfach 5001 an.
Hallo Jens,
scheinbar hast du es so wie beschrieben nicht getestet.
Also einfach 2. Instanz mit passender Verbindung definieren (natürlich vor dem pilight_temp). Für den Empfang funktioniert das nämlich bereits.
pilight_temp würde die Daten von beiden Geräten bekommen, wenn diese die Signale empfangen.
Für das Senden ging es noch nicht. Das habe ich heute nachgepflegt und ist morgen verfügbar.
Man kann nun das IODev über das Attribut verstellen. Das ist sogar in fhem.pl schon vorgesehen.
Eine andere Möglichkeit wäre über FHEM2FHEM zu gehen. Also auf beiden Pi jeweils einen FHEM-Server laufen zu lassen (1 Master und einer Slave).
Risiko
Hallo Risiko,
ich hatte das schon so eingerichtet, aber da in meinem piligh_temp Gerät das iOdev nicht explizit irgendwie zugewiesen werden kann (es steht da halt immer unter ioDev das 1. myctrl drin) bin ich nicht davon ausgegangen das es klappt.
Ich werde das am Wochenende noch mal testen.
:-)
Grüße
Jens
Zitat von: Risiko am 17 Dezember 2015, 19:54:50
Eine andere Möglichkeit wäre über FHEM2FHEM zu gehen. Also auf beiden Pi jeweils einen FHEM-Server laufen zu lassen (1 Master und einer Slave).
Risiko
Das mit FHEM2FHEM wollte ich zunächst nicht machen. Weil ich den 2. Rapsberry unter anderem als Ausfallsicherung für den 1. FHEM Server nutze.
Ich überwache den 1. FHEM Raspberry und sobald dieser ausfällt wird auf dem 2 FHEM mit dergleichen Konfig gestartet.
Das mache ich wechselseitig, so das auf jedenfall ein FHEM immer läuft.
Gruß
Jens
Hallo, ich habe ein kleines Problem beim Schalten meiner IT-1500 über FHEM. Ich habe die 3 Dosen in die GUI eingebunden und kann sie auch schalten. Allerdings klappt das über die FHEM Gui genau einmal, danach muss ich den Pilight Daemon resetten, damit ich wieder schalten kann. Im LOG sehe ich diese Einträge
2015.12.21 15:13:03 3: pilight: Unknown code PISWITCH,clarus_switch,F11,24,on, help me!
2015.12.21 15:13:59 3: Opening pilight device 192.168.0.26:6000
2015.12.21 15:13:59 3: pilight device opened
2015.12.21 15:14:10 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/Blocking.pm line 107.
2015.12.21 15:14:10 1: BlockingInformParent (pilight_ctrl_SendDone): Can't connect to localhost:: IO::Socket::INET: Bad hostname 'localhost:'
2015.12.21 15:15:29 3: Opening pilight device 192.168.0.26:6000 2015.12.21 15:15:29 3: pilight device opened
2015.12.21 15:15:41 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/Blocking.pm line 107.
2015.12.21 15:15:41 1: BlockingInformParent (pilight_ctrl_SendDone): Can't connect to localhost:: IO::Socket::INET: Bad hostname 'localhost:'
Ausserdem bekomme ich massig Fehlermeldungen wie
...pilight: unknown code PISWITCH,elro_800_switch_old,8,21,on,help me!
Die sind aber scheinbar neu, die gab es am Samstag noch nicht.
Wenn ich über Putty mit pilight schalte, klappt alles wunderbar. An und Aus nach belieben und wie gewünscht. Hat jemand einen Idee?
Zitat von: Domjo75 am 21 Dezember 2015, 15:37:55
Hallo, ich habe ein kleines Problem beim Schalten meiner IT-1500 über FHEM. Ich habe die 3 Dosen in die GUI eingebunden und kann sie auch schalten. Allerdings klappt das über die FHEM Gui genau einmal, danach muss ich den Pilight Daemon resetten, damit ich wieder schalten kann. Im LOG sehe ich diese Einträge
2015.12.21 15:13:03 3: pilight: Unknown code PISWITCH,clarus_switch,F11,24,on, help me!
2015.12.21 15:13:59 3: Opening pilight device 192.168.0.26:6000
2015.12.21 15:13:59 3: pilight device opened
2015.12.21 15:14:10 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/Blocking.pm line 107.
2015.12.21 15:14:10 1: BlockingInformParent (pilight_ctrl_SendDone): Can't connect to localhost:: IO::Socket::INET: Bad hostname 'localhost:'
2015.12.21 15:15:29 3: Opening pilight device 192.168.0.26:6000 2015.12.21 15:15:29 3: pilight device opened
2015.12.21 15:15:41 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/Blocking.pm line 107.
2015.12.21 15:15:41 1: BlockingInformParent (pilight_ctrl_SendDone): Can't connect to localhost:: IO::Socket::INET: Bad hostname 'localhost:'
Liegt irgendwie am Modul Blocking. Schon mal ein Update probiert?
Es kann localhost
: nicht aufgelöst werden. Da ist scheinbar ein
: zu viel.
Schau mal hier: http://forum.fhem.de/index.php/topic,44764.msg366081.html#msg366081
Zitat von: Domjo75 am 21 Dezember 2015, 15:37:55
Ausserdem bekomme ich massig Fehlermeldungen wie
...pilight: unknown code PISWITCH,elro_800_switch_old,8,21,on,help me!
Die sind aber scheinbar neu, die gab es am Samstag noch nicht.
Das wurde hier schon öfters im Thread behandelt. Einfach mal suchen.
Hi,
der Tipp mit Telnet war goldrichtig. :) Ich kann jetzt schalten wie gewünscht. Jetzt muss ich nur noch die anderen Meldungen weg bekommen. Aber nicht mehr heute. Ich poste die Lösung, wenn ich eine finde :)
Gesendet von meinem SM-T310 mit Tapatalk
Achso... Danke für die Unterstützung
Gesendet von meinem SM-T310 mit Tapatalk
so, auch der letzte Fehler ist weg.
Der Eintrag attr pilight ignoreProtocol * hat´s gerichtet. Auch wenn ich das nicht verstehe... :)
Hallo zusammen,
ich hab hier die pililght module seit geraumer Zeit im Einsatz. und nun mußte ich feststellen, als die Temperaturen die letzten tage unter 0 waren, das die Daten von meinem Technika sensor scheinbar nicht korrekt ausgewertet werden. Ich vermute mal es liegt nicht am pilight_ctrl Modul sondern an pilight selber...
Anbei mal das rcv_raw reading bei einer Temperatur von -5 Grad:
{"message":{"id":204.0,"temperature":97.4,"humidity":88.0,"battery":0.0},"origin":"receiver","protocol":"teknihall","uuid":"0000-b8-27-eb-a9aa94","repeats":2}
Hm, tja dumm gelaufen...
Gruß
Jens
Hallo Jens,
es liegt meiner Meinung nach nicht an den FHEM-Modulen. Die empfangene Message hat schon die unsinnige Temperatur.
Folgende Ideen:
Batterie wechseln. Wenn das das richtig interpretiert wird, ist die leer.
Empfänger und Sensor zum Test mal näher zusammen bringen
Evtl. ein Bug, mal im pilight Forum suchen
Tritt das Verhalten nur bei negativen Werten auf? Korreliert es evtl. mit Richter_Wert = Temp - 100 also im Beispiel mit -2.6°C ?
Hallo Risiko,
ja, das es nicht an Deinen Modulen liegt dachte ich mir. Das Problem scheint pilight selbst zu sein. Die Batterien sind neu. Der dazugehörige Empfänger zum Sensor zeigt die richtige Temp auch an. Auch das Display am Sensor selber zeigt die richtige Temp.
Ich denke pilight decodiert das irgendwas falsch.
Das Verhalten tritt nur bei negativen Werten (bzw 0 Grad) auf.
ZitatKorreliert es evtl. mit Richter_Wert = Temp - 100 also im Beispiel mit -2.6°C ?
Was meinst Du damit?
Gruß
Jens
Zitat von: Jens_B am 04 Januar 2016, 06:51:00
Das Verhalten tritt nur bei negativen Werten (bzw 0 Grad) auf.Was meinst Du damit?
War nur so ne blöde Idee:
Also richtiger Wert auf dem Display des Sensors war -2.6° (97.4-100). Pilight hat daraus aber 97.4 gemacht.
ZitatWar nur so ne blöde Idee:
Also richtiger Wert auf dem Display des Sensors war -2.6° (97.4-100). Pilight hat daraus aber 97.4 gemacht.
Also es scheint nicht -100 zu sein, sondern 102,4
97,3 angezeigt = richtiger Wert -5,1 Grad
97,2 angezeigt = richtiger Wert -5,2 Grad
97,1 angezeigt = richtiger Wert -5,3 Grad...
Ich vermute einfach mal einen Bug in pilight, habe das auch schon im pilight forum gepostet. Aber curlymoo hat darauf bisher nicht reagiert.
Gruß
Jens
So ich habe jetzt eine korrigierte Pilight Version compiliert (von hier: https://forum.pilight.org/Thread-negative-Temperature-for).
Damit scheint es zu funktionieren.
Gruß
Jens
Glückwunsch :D
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.
Jetzt kam mir die Idee das Klingelsignal mit Pilight-raw aufzuzeichnen. Wenn ich das aufgezeichnete Signal wieder sende klingelt es. Soweit so gut.
Jetzt würde ich es gerne klingeln lassen, aber es scheitert daran nicht weiß wie ich in FHEM auf das raw-Signal des Klingeltasters triggern kann.
Hat jemand eine Idee wie sich das realisieren lässt?
... also ich würde das Reading aus pilight_ctrl auseinandernehmen und es in FHEM über ein DOIF abfragen.
In etwa so:
Zitatdefine KLINGELT DOIF ([myctrl:state] eq ("irgendwas") (set KLINGEL an)
Zitat von: Jens_B am 08 Januar 2016, 14:39:24
... also ich würde das Reading aus pilight_ctrl auseinandernehmen und es in FHEM über ein DOIF abfragen.
In etwa so:
Wo sehe ich denn das Reading? Liest/wertet der auch unbekannte (raw) Signale aus?
Zitat von: derchrome am 08 Januar 2016, 20:01:52
Wo sehe ich denn das Reading? Liest/wertet der auch unbekannte (raw) Signale aus?
Pilight-receive funktioniert nur mit in pilight umgesetzten Protokollen. Das ist die Grundlage, das pilight_ctrl was mitbekommt.
Also wenn das Klingelsignal nicht einem umgesetzten Protokoll entspricht, sehe ich da aktuell keine Chancen.
Hi alle zusammen,
Ich bin gerade dabei mein Fhem einzurichten, und habe da ein kleines Problem. und zwar will sich Fhem nicht mit pilight verbinden.
Ich bin folgender Maßen vorgegangen.
In die Befehlszeile oben habe ich
define WZ pilight_ctrl 192.168.178.37:5000 eingegeben.
Dann habe ich mit
define Switch pilight_switch kaku_switch 19864566 0 nen "Schalter" erugt
Anschließend hab ich in der pilight config.json den Port 5000 geändert
Siehe hier
"settings": {
"log-level": 6,
"pid-file": "/var/run/pilight.pid",
"log-file": "/var/log/pilight.log",
"webserver-enable": 1,
"webserver-root": "/usr/local/share/pilight/",
"webserver-http-port": 5000,
"webserver-cache": 1
},
"hardware": {
"433gpio": {
"sender": 0,
"receiver": 1
}
},
"registry": {
"pilight": {
"version": {
"current": "7.0"
}
}
}
}
Wenn ich dann in der Fhem einen reset durchführe, geht der Status von disconnected auf opened. Anschließend wieder auf disconnected.
Hier der log
2016.02.01 11:19:23 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:19:23 3: WZ device opened
2016.02.01 11:19:23 1: Including ./log/fhem.save
2016.02.01 11:19:23 1: usb create starting
2016.02.01 11:19:25 3: Probing CUL device /dev/ttyAMA0
2016.02.01 11:19:25 3: Probing TCM_ESP3 device /dev/ttyAMA0
2016.02.01 11:19:26 3: Probing FRM device /dev/ttyAMA0
2016.02.01 11:19:31 1: usb create end
2016.02.01 11:19:31 2: SecurityCheck: WEB,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.02.01 11:19:31 0: Featurelevel: 5.7
2016.02.01 11:19:31 0: Server started with 11 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 2016)
2016.02.01 11:19:42 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:20:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:20:46 3: WZ device opened
2016.02.01 11:20:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:22:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:22:01 3: WZ device opened
2016.02.01 11:22:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:23:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:23:16 3: WZ device opened
2016.02.01 11:23:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:24:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:24:31 3: WZ device opened
2016.02.01 11:24:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:25:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:25:46 3: WZ device opened
2016.02.01 11:25:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:27:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:27:01 3: WZ device opened
2016.02.01 11:27:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:28:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:28:16 3: WZ device opened
2016.02.01 11:28:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:29:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:29:31 3: WZ device opened
2016.02.01 11:29:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:30:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:30:46 3: WZ device opened
2016.02.01 11:30:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:32:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:32:01 3: WZ device opened
2016.02.01 11:32:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:33:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:33:16 3: WZ device opened
2016.02.01 11:33:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:34:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:34:31 3: WZ device opened
2016.02.01 11:34:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:35:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:35:46 3: WZ device opened
2016.02.01 11:35:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:37:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:37:01 3: WZ device opened
2016.02.01 11:37:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:38:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:38:16 3: WZ device opened
2016.02.01 11:38:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:39:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:39:31 3: WZ device opened
2016.02.01 11:39:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:40:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:40:46 3: WZ device opened
2016.02.01 11:40:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:42:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:42:01 3: WZ device opened
2016.02.01 11:42:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:43:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:43:16 3: WZ device opened
2016.02.01 11:43:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:44:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:44:31 3: WZ device opened
2016.02.01 11:44:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:45:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:45:46 3: WZ device opened
2016.02.01 11:45:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:47:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:47:01 3: WZ device opened
2016.02.01 11:47:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:48:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:48:16 3: WZ device opened
2016.02.01 11:48:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:49:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:49:31 3: WZ device opened
2016.02.01 11:49:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:50:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:50:46 3: WZ device opened
2016.02.01 11:50:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:52:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:52:01 3: WZ device opened
2016.02.01 11:52:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:53:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:53:16 3: WZ device opened
2016.02.01 11:53:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:54:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:54:31 3: WZ device opened
2016.02.01 11:54:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:55:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:55:46 3: WZ device opened
2016.02.01 11:55:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:57:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:57:01 3: WZ device opened
2016.02.01 11:57:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:58:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:58:16 3: WZ device opened
2016.02.01 11:58:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 11:59:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 11:59:31 3: WZ device opened
2016.02.01 11:59:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:00:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:00:46 3: WZ device opened
2016.02.01 12:00:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:02:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:02:01 3: WZ device opened
2016.02.01 12:02:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:03:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:03:16 3: WZ device opened
2016.02.01 12:03:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:04:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:04:31 3: WZ device opened
2016.02.01 12:04:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:05:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:05:46 3: WZ device opened
2016.02.01 12:05:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:07:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:07:01 3: WZ device opened
2016.02.01 12:07:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:08:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:08:16 3: WZ device opened
2016.02.01 12:08:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:09:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:09:31 3: WZ device opened
2016.02.01 12:09:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:10:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:10:46 3: WZ device opened
2016.02.01 12:10:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:12:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:12:01 3: WZ device opened
2016.02.01 12:12:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:13:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:13:16 3: WZ device opened
2016.02.01 12:13:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:14:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:14:31 3: WZ device opened
2016.02.01 12:14:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:15:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:15:46 3: WZ device opened
2016.02.01 12:15:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:17:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:17:01 3: WZ device opened
2016.02.01 12:17:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:18:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:18:16 3: WZ device opened
2016.02.01 12:18:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:19:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:19:31 3: WZ device opened
2016.02.01 12:19:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:20:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:20:46 3: WZ device opened
2016.02.01 12:20:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:22:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:22:01 3: WZ device opened
2016.02.01 12:22:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:23:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:23:16 3: WZ device opened
2016.02.01 12:23:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:24:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:24:31 3: WZ device opened
2016.02.01 12:24:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:25:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:25:46 3: WZ device opened
2016.02.01 12:25:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:27:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:27:01 3: WZ device opened
2016.02.01 12:27:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:28:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:28:16 3: WZ device opened
2016.02.01 12:28:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:29:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:29:31 3: WZ device opened
2016.02.01 12:29:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:30:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:30:46 3: WZ device opened
2016.02.01 12:30:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:32:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:32:01 3: WZ device opened
2016.02.01 12:32:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:33:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:33:16 3: WZ device opened
2016.02.01 12:33:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:34:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:34:31 3: WZ device opened
2016.02.01 12:34:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:35:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:35:46 3: WZ device opened
2016.02.01 12:35:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:37:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:37:01 3: WZ device opened
2016.02.01 12:37:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:38:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:38:16 3: WZ device opened
2016.02.01 12:38:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:39:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:39:31 3: WZ device opened
2016.02.01 12:39:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:40:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:40:46 3: WZ device opened
2016.02.01 12:40:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:42:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:42:01 3: WZ device opened
2016.02.01 12:42:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:43:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:43:16 3: WZ device opened
2016.02.01 12:43:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:44:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:44:31 3: WZ device opened
2016.02.01 12:44:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:45:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:45:46 3: WZ device opened
2016.02.01 12:45:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:47:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:47:01 3: WZ device opened
2016.02.01 12:47:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:48:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:48:16 3: WZ device opened
2016.02.01 12:48:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:49:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:49:31 3: WZ device opened
2016.02.01 12:49:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:50:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:50:46 3: WZ device opened
2016.02.01 12:50:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:52:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:52:01 3: WZ device opened
2016.02.01 12:52:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:53:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:53:16 3: WZ device opened
2016.02.01 12:53:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:54:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:54:31 3: WZ device opened
2016.02.01 12:54:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:55:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:55:46 3: WZ device opened
2016.02.01 12:55:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:57:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:57:01 3: WZ device opened
2016.02.01 12:57:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:58:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:58:16 3: WZ device opened
2016.02.01 12:58:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 12:59:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 12:59:31 3: WZ device opened
2016.02.01 12:59:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:00:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:00:46 3: WZ device opened
2016.02.01 13:00:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:02:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:02:01 3: WZ device opened
2016.02.01 13:02:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:03:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:03:16 3: WZ device opened
2016.02.01 13:03:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:04:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:04:31 3: WZ device opened
2016.02.01 13:04:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:05:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:05:46 3: WZ device opened
2016.02.01 13:05:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:07:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:07:01 3: WZ device opened
2016.02.01 13:07:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:08:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:08:16 3: WZ device opened
2016.02.01 13:08:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:09:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:09:31 3: WZ device opened
2016.02.01 13:09:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:10:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:10:46 3: WZ device opened
2016.02.01 13:10:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:12:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:12:01 3: WZ device opened
2016.02.01 13:12:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:13:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:13:16 3: WZ device opened
2016.02.01 13:13:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:14:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:14:31 3: WZ device opened
2016.02.01 13:14:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:15:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:15:46 3: WZ device opened
2016.02.01 13:15:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:17:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:17:01 3: WZ device opened
2016.02.01 13:17:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:18:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:18:16 3: WZ device opened
2016.02.01 13:18:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:19:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:19:31 3: WZ device opened
2016.02.01 13:19:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:20:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:20:46 3: WZ device opened
2016.02.01 13:20:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:22:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:22:01 3: WZ device opened
2016.02.01 13:22:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:23:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:23:16 3: WZ device opened
2016.02.01 13:23:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:24:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:24:31 3: WZ device opened
2016.02.01 13:24:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:25:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:25:46 3: WZ device opened
2016.02.01 13:25:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:27:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:27:01 3: WZ device opened
2016.02.01 13:27:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:28:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:28:16 3: WZ device opened
2016.02.01 13:28:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:29:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:29:31 3: WZ device opened
2016.02.01 13:29:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:30:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:30:46 3: WZ device opened
2016.02.01 13:30:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:32:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:32:01 3: WZ device opened
2016.02.01 13:32:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:33:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:33:16 3: WZ device opened
2016.02.01 13:33:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:34:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:34:31 3: WZ device opened
2016.02.01 13:34:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:35:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:35:46 3: WZ device opened
2016.02.01 13:35:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:37:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:37:01 3: WZ device opened
2016.02.01 13:37:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:38:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:38:16 3: WZ device opened
2016.02.01 13:38:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:39:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:39:31 3: WZ device opened
2016.02.01 13:39:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:40:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:40:46 3: WZ device opened
2016.02.01 13:40:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:42:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:42:01 3: WZ device opened
2016.02.01 13:42:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:43:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:43:16 3: WZ device opened
2016.02.01 13:43:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:44:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:44:31 3: WZ device opened
2016.02.01 13:44:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:45:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:45:46 3: WZ device opened
2016.02.01 13:45:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:47:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:47:01 3: WZ device opened
2016.02.01 13:47:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:48:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:48:16 3: WZ device opened
2016.02.01 13:48:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:49:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:49:31 3: WZ device opened
2016.02.01 13:49:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:50:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:50:46 3: WZ device opened
2016.02.01 13:50:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:52:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:52:01 3: WZ device opened
2016.02.01 13:52:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:53:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:53:16 3: WZ device opened
2016.02.01 13:53:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:54:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:54:31 3: WZ device opened
2016.02.01 13:54:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:55:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:55:46 3: WZ device opened
2016.02.01 13:55:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:57:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:57:01 3: WZ device opened
2016.02.01 13:57:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:58:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:58:16 3: WZ device opened
2016.02.01 13:58:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 13:59:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 13:59:31 3: WZ device opened
2016.02.01 13:59:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:00:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:00:46 3: WZ device opened
2016.02.01 14:00:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:02:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:02:01 3: WZ device opened
2016.02.01 14:02:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:03:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:03:16 3: WZ device opened
2016.02.01 14:03:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:04:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:04:31 3: WZ device opened
2016.02.01 14:04:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:05:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:05:46 3: WZ device opened
2016.02.01 14:05:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:07:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:07:01 3: WZ device opened
2016.02.01 14:07:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:08:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:08:16 3: WZ device opened
2016.02.01 14:08:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:09:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:09:31 3: WZ device opened
2016.02.01 14:09:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:10:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:10:46 3: WZ device opened
2016.02.01 14:10:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:12:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:12:01 3: WZ device opened
2016.02.01 14:12:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:13:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:13:16 3: WZ device opened
2016.02.01 14:13:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:14:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:14:31 3: WZ device opened
2016.02.01 14:14:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:15:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:15:46 3: WZ device opened
2016.02.01 14:15:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:17:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:17:01 3: WZ device opened
2016.02.01 14:17:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:18:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:18:16 3: WZ device opened
2016.02.01 14:18:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:19:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:19:31 3: WZ device opened
2016.02.01 14:19:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:20:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:20:46 3: WZ device opened
2016.02.01 14:20:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:22:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:22:01 3: WZ device opened
2016.02.01 14:22:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:23:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:23:16 3: WZ device opened
2016.02.01 14:23:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:24:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:24:31 3: WZ device opened
2016.02.01 14:24:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:25:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:25:46 3: WZ device opened
2016.02.01 14:25:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:27:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:27:01 3: WZ device opened
2016.02.01 14:27:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:28:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:28:16 3: WZ device opened
2016.02.01 14:28:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:29:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:29:31 3: WZ device opened
2016.02.01 14:29:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:30:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:30:46 3: WZ device opened
2016.02.01 14:30:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:32:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:32:01 3: WZ device opened
2016.02.01 14:32:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:33:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:33:16 3: WZ device opened
2016.02.01 14:33:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:34:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:34:31 3: WZ device opened
2016.02.01 14:34:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:35:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:35:46 3: WZ device opened
2016.02.01 14:35:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:37:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:37:01 3: WZ device opened
2016.02.01 14:37:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:38:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:38:16 3: WZ device opened
2016.02.01 14:38:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:39:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:39:31 3: WZ device opened
2016.02.01 14:39:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:40:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:40:46 3: WZ device opened
2016.02.01 14:40:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:42:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:42:01 3: WZ device opened
2016.02.01 14:42:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:43:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:43:16 3: WZ device opened
2016.02.01 14:43:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:44:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:44:31 3: WZ device opened
2016.02.01 14:44:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:45:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:45:46 3: WZ device opened
2016.02.01 14:45:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:47:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:47:01 3: WZ device opened
2016.02.01 14:47:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:48:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:48:16 3: WZ device opened
2016.02.01 14:48:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:49:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:49:31 3: WZ device opened
2016.02.01 14:49:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:50:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:50:46 3: WZ device opened
2016.02.01 14:50:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:52:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:52:01 3: WZ device opened
2016.02.01 14:52:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:53:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:53:16 3: WZ device opened
2016.02.01 14:53:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:54:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:54:31 3: WZ device opened
2016.02.01 14:54:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:55:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:55:46 3: WZ device opened
2016.02.01 14:55:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:57:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:57:01 3: WZ device opened
2016.02.01 14:57:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:58:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:58:16 3: WZ device opened
2016.02.01 14:58:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 14:59:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 14:59:31 3: WZ device opened
2016.02.01 14:59:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:00:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:00:46 3: WZ device opened
2016.02.01 15:00:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:02:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:02:01 3: WZ device opened
2016.02.01 15:02:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:03:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:03:16 3: WZ device opened
2016.02.01 15:03:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:04:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:04:31 3: WZ device opened
2016.02.01 15:04:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:05:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:05:46 3: WZ device opened
2016.02.01 15:05:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:07:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:07:01 3: WZ device opened
2016.02.01 15:07:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:08:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:08:16 3: WZ device opened
2016.02.01 15:08:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:09:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:09:31 3: WZ device opened
2016.02.01 15:09:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:10:20 2: WZ(Write): ERROR: no connection to pilight-daemon 192.168.178.37:5000
2016.02.01 15:10:22 2: WZ(Write): ERROR: no connection to pilight-daemon 192.168.178.37:5000
2016.02.01 15:10:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:10:46 3: WZ device opened
2016.02.01 15:10:56 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:10:57 2: WZ(Check): Could not connect to pilight-daemon 192.168.178.37:5000
2016.02.01 15:11:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:11:46 3: Can't connect to 192.168.178.37:5000: Connection refused
2016.02.01 15:11:47 2: WZ(Check): Could not connect to pilight-daemon 192.168.178.37:5000
2016.02.01 15:12:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:12:46 3: Can't connect to 192.168.178.37:5000: Connection refused
2016.02.01 15:12:47 2: WZ(Check): Could not connect to pilight-daemon 192.168.178.37:5000
2016.02.01 15:13:22 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:13:22 3: Can't connect to 192.168.178.37:5000: Connection refused
2016.02.01 15:13:23 2: WZ(Check): Could not connect to pilight-daemon 192.168.178.37:5000
2016.02.01 15:13:28 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:13:28 3: Can't connect to 192.168.178.37:5000: Connection refused
2016.02.01 15:13:29 2: WZ(Check): Could not connect to pilight-daemon 192.168.178.37:5000
2016.02.01 15:13:38 3: Opening WZ device 192.168.178.37:5001
2016.02.01 15:13:38 3: Can't connect to 192.168.178.37:5001: Connection refused
2016.02.01 15:13:39 2: WZ(Check): Could not connect to pilight-daemon 192.168.178.37:5001
2016.02.01 15:13:43 3: Opening WZ device 192.168.178.37:5001
2016.02.01 15:13:43 3: Can't connect to 192.168.178.37:5001: Connection refused
2016.02.01 15:13:44 2: WZ(Check): Could not connect to pilight-daemon 192.168.178.37:5001
2016.02.01 15:14:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:14:31 3: WZ device opened
2016.02.01 15:14:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:14:48 2: WZ(Write): ERROR: no connection to pilight-daemon 192.168.178.37:5000
2016.02.01 15:14:50 2: WZ(Write): ERROR: no connection to pilight-daemon 192.168.178.37:5000
2016.02.01 15:15:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:15:46 3: WZ device opened
2016.02.01 15:15:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:17:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:17:01 3: WZ device opened
2016.02.01 15:17:13 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:18:16 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:18:16 3: WZ device opened
2016.02.01 15:18:28 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:19:31 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:19:31 3: WZ device opened
2016.02.01 15:19:43 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:20:46 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:20:46 3: WZ device opened
2016.02.01 15:20:58 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)
2016.02.01 15:22:01 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:22:01 3: WZ device opened
2016.02.01 15:22:14 3: Opening WZ device 192.168.178.37:80
2016.02.01 15:22:14 3: Can't connect to 192.168.178.37:80: Connection refused
2016.02.01 15:22:15 2: WZ(Check): Could not connect to pilight-daemon 192.168.178.37:80
2016.02.01 15:23:18 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:23:18 3: WZ device opened
2016.02.01 15:23:29 3: Opening WZ device 192.168.178.37:5000
2016.02.01 15:23:29 3: WZ device opened
2016.02.01 15:23:41 1: 192.168.178.37:5000 disconnected, waiting to reappear (WZ)Dann hab ich folgendes gefunden
ZitatRisiko:
@update71
Es kann keine Verbindung zu pilight aufgebaut werden!!
Verwechselst du nicht webserver-port für die WebGui und den pilight Port für die Kommunikation!!??
--- Code: ---settings": {
"port": 5000,
"webserver-port": 5001,
}
--- Ende Code ---
Risiko.
Also habe ich die config.json um die Zeile "port" 5000, erweitert.
Anschließend konnte ich pilight nicht mehr starten.
Ich dreh mich ab jetzt im Kreis, und vermute das ich ohne Hilfe nicht mehr raus komme.
MfG
Port 5000 ist schon richtig. Dein http Port muss dann raus gelöscht werden
Gesendet von meinem C6603 mit Tapatalk
Du kannst natürlich nicht beide Ports mit der gleichen Portnummer versehen.
Also entweder so wie es sash.sc sagt den http Port raus oder eine andere Nummer vergeben.
Hallo zusammen,
an sich funktioniert alles super - vielen Dank für die Module und die vielen Posts dazu - aber dennoch habe ich ein kleinen Problem.
Ich hatte bis dato meine Funksteckdosen via IT-Modul und CUL (868MHz) gesteuert. Das klappt auch meistens. Nun wollte ich auf 433MHz umstellen und habe mir ein TX- und RX-Modul besorgt, mit meinem BananaPi verbunden, ein paar Module installiert und in der Config-Datei einfach die Zeilen mit der IT-Definition durch die pilght-switch-Definition getauscht. Pilight-ctlr wurde natürlich auch definiert.
Mit pilight-receive habe ich geprüft, was denn als Protokoll gesendet wurde ("sc2262"). Leider hat das mit pilight_switch nicht geklappt. Durch etwas stöbern im Forum bin ich dann auf das Protokoll "elro_800_switch" gekommen. Damit, und mit den im pilight-receive angezeigten System- und Unit-Codes habe ich dann die Definitionen der jeweiligen Schalter angelegt:
define C1 pilight_switch elro_800_switch 29 15
define C3 pilight_switch elro_800_switch 29 14
Das hat auch bei einem Teil der Steckdosen zum sofortigen Erfolg geführt - nur nicht bei allen - und das ist nun mein Problem:
Intertechno ITR-1500 (die Weissen, selbstlernenden) Funksteckdosen lassen sich nur ausschalten, aber nicht einschalten. Die erste Zeile mit "State : off", zeigt den Log-Eintrag für das Ausschalten, die zweite mit "State : on" das Anschalten. Off geht, On leider nicht.
2016-02-06_12:53:05 MyPilight rcv_raw: {"origin":"sender","protocol":"elro_800_switch","message":{"systemcode":29,"unitcode":14,"state":"off"},"repeat":1,"uuid":"0000-02-13-09-00eb18"}
2016-02-06_12:53:07 MyPilight rcv_raw: {"origin":"sender","protocol":"elro_800_switch","message":{"systemcode":29,"unitcode":14,"state":"on"},"repeat":1,"uuid":"0000-02-13-09-00eb18"}
Ich habe kein Attribut "brands" in pilight-ctrl definiert. Aber auch mit diversen Versuche mit "brands" habe ich es nicht hinbekommen.
Die System- und Unit-Codes funktionieren mit IT problemlos auch mit den ITR-1500 Dosen.
Ich hatte mit
define C3 pilight_switch kaku_switch 4466531 0
zwar Erfolg beim Einschalten, nur muss ich dann die ganzen IDs ermitteln / neu anlernen. Ich hoffe, es gibt einen Weg die alten IT-Codes verwenden zu können.
Hat jemand einen Tipp dazu?
Vielen Dank und Gruß
Bernd[/code]
Hallo Bernd,
ich kann in den Logs keinen Fehler in den FHEM-Modulen sehen.
Ich finde deine Beschreibung aber sehr seltsam:
1. Das Protokoll sc2262 scheint es offiziell zu geben - oder ich übersehe etwas: https://wiki.pilight.org/doku.php/protocols#switches
2. Protokoll elro_800_switch und kaku_switch sind nicht verwand. Wieso soll es denn bei dem einen gehen und bei dem anderen nicht.
Meiner Meinung nach ist für die selbstlernenden Intertechno das Protokoll kaku_switch das Richtige.
Für nicht selbstlernenden IT das Protokoll kaku_switch_old.
Wenn du auch einen Empfänger angeschlossen hast, kannst doch einfach die ID's mit pilight-receive ohne neu zu lernen ermitteln.
Risiko
Hallo Risiko,
danke für die schnelle Reaktion.
Ich habe diese weissen ITR-1500 alle mit den IT-Codes aus FHEM angelernt. Device in FHEM definiert (define B1 IT F00000000F FF F0), Steckdose in die Wand und auf ON geklickt. Damit war die Dose zufrieden und funktionierte aus FHEM. Die Fernbedienungen ITT-1500 habe ich nie verwendet.
Wenn ich nun die Kommunikation zwischen FHEM-CUL und ITR-1500 ansehe, bekomme ich für ein ON das:
{
"message": {
"systemcode": 29,
"unitcode": 14,
"state": "opened"
},
"origin": "receiver",
"protocol": "sc2262",
"uuid": "0000-02-13-09-00eb18",
"repeats": 1
}
{
"message": {
"systemcode": 29,
"unitcode": 14,
"state": "opened"
},
"origin": "receiver",
"protocol": "sc2262",
"uuid": "0000-02-13-09-00eb18",
"repeats": 2
}
Ich hatte gehofft, diese Codes in Pilight verwenden zu können. Leider geht damit nur ein OFF.
Wenn ich nun mit der IT-Fernbedienung ITT-1500 eine Dose anlerne, bekomme ich das in pilight-receive:
{
"message": {
"id": 17806006,
"unit": 2,
"state": "on"
},
"origin": "receiver",
"protocol": "arctech_switch",
"uuid": "0000-02-13-09-00eb18",
"repeats": 4
}
{
"message": {
"id": 17806006,
"unit": 2,
"state": "opened"
},
"origin": "receiver",
"protocol": "arctech_contact",
"uuid": "0000-02-13-09-00eb18",
"repeats": 4
}
{
"message": {
"id": 17806006,
"unit": 2,
"state": "up"
},
"origin": "receiver",
"protocol": "arctech_screen",
"uuid": "0000-02-13-09-00eb18",
"repeats": 4
}
Damit kann ich dann zwar ein pilight-switch definieren (define C3 pilight_switch kaku_switch 4466531 0), aber dann muss ich diese 8-stelligen Codes alle erzeugen/ermitteln. Das wollte ich eigentlich vermeiden. Die Dose sind nicht alle so schön zugänglich.
Der Versuch. mit kaku_switch einen Code anzulernen hatte leider auch keinen Erfolg. Ein
pilight-send -p kaku_switch -i 12345678 -u 0 -t -l
war leider auch nicht erfolgreich. Die Dose hat es nicht akzeptiert.
Bernd
Nachtrag zu ITR-1500: Sie funktionieren mit den alten IT-Codes und dem Pollin-Protokoll :)
pilight: pilight-send -p pollin -s 29 -u 14 -f
oder
FHEM define C3 pilight_switch pollin 29 14
Nur der STATE ist jetzt immer auf "defined". (Nachtrag: STATE geht - reboot (shutdown restart) tut gut)
Bernd
Hallo Bernd,
es ist schön, dass es geht. Verstehen tue ich es aber nicht.
Pollin für IT - sehr seltsam.
Das Protokoll sc2262 ist laut Doku für eine Kontaktsensor.
arctech_switch ist ein anderer Name für Kaku_switch, intertechno_switch - Stichwort brands.
Mit define pilight_switch kaku_switch 17806006 2 hätte es gehen müssen.
Naja, es geht ja jetzt.
Viel Spaß.
Hallo Risiko,
DEFINE C3 pilight_switch kaku_switch 17806006 2
hat funktioniert. Nur wollte ich nicht unnötigerweise die ganzen IDs ermitteln.
Mit dem POLLIN Protokoll läuft es jetzt super.
Vielen Dank nochmal für das Modul und den Support.
Gruß
Bernd
Hallo zusammen
ich bin gerade dabei auf FHEM umzusteigen. Die Steuerung von Funksteckdosen funktioniert auch schon. Meine LED-Dimmer kann ich zwar schalten, aber leider über die Oberfläche nicht dimmen.
Kann mir da jemand einen Tip geben wie ich das Module pilight_dimmer konfigurieren muss?
Hier die entsprechenden Zeilen aus der Pilight-Konfiguration:
"dimmer1": {
"protocol": [ "kaku_dimmer" ],
"id": [{
"id": 100,
"unit": 0
}],
"state": "off",
"dimlevel": 0
und entsprechend aus meiner jetzigen FHEM-Datei:
## Dimmer1 Wohnzimmer ##
define Gesamtwohnen pilight_dimmer kaku_dimmer 100 0 kaku_screen
attr Gesamtwohnen IODev pilight
attr Gesamtwohnen group EG
attr Gesamtwohnen room Wohnzimmer
Bin für jeden Tip dankbar. Danke
Oldsurfer
Hallo,
Das Kaku_Screenshots ist in jedem Fall zuviel.
Hier ist meine Definition als Beispiel:
define TeDachLicht pilight_dimmer kaku_dimmer 6266126 0
attr TeDachLicht userattr Erdgeschoss Erdgeschoss_map structexclude
attr TeDachLicht Erdgeschoss EGRaeume
attr TeDachLicht IODev PilightSrv1
attr TeDachLicht alias Dachbeleuchtung
attr TeDachLicht cmdIcon ein:Restart aus:Shutdown
attr TeDachLicht comment {if(ReadingsVal($name,"state","") eq 'off') {"off"} else {ReadingsVal($name,"dimlevel",0)}}
attr TeDachLicht devStateIcon 0:dim06% 1:dim12% 2:dim18% 3:dim25% 4:dim31% 5:dim37% 6:dim43% 7:dim50% 8:dim56% 9:dim62% 10:dim68% 11:dim75% 12:dim81% 13:dim87% 14:dim93% 15:dim100%
attr TeDachLicht eventMap on:ein off:aus
attr TeDachLicht fp_wohnzimmer 200,800,5,
attr TeDachLicht group Dach
attr TeDachLicht room Terrasse
attr TeDachLicht stateFormat {if(ReadingsVal($name,"state","") eq 'off') {"off"} else {ReadingsVal($name,"dimlevel",0)}}
attr TeDachLicht webCmd dimlevel:ein:aus
Vielleicht ist es hilfreich
Super, das war genu was ich gesucht hatte.
Vielen Dank :-)
Hallo Oldsurfer
Das sollte auch mit der Zugabe des 2. Protokolls Screen gehen.
Zusätzlich hätte man hier eben noch die Funktion Up und Down.
Man muss dann natürlich das attr webcmd anpassen:
attr Gesamtwohnen webCmd on:off:up:down:dimlevel
Hallo Risiko
die Lösung ist natürlich viel einfacher umzusetzen. Ich habe nur die up:down Anweisungen weggelassen. Den Level kann man auch gut mit dem Dimlevel einstellen.
Oldsurfer
Wie installiere ich denn das Modul ?
Immer wenn ich mit pilight_temp arbeiten möchte, kennt er es nicht.
Habe "UPDATE" durchgeführt jedoch bekomme ich immer noch folgende Meldung:
"Cannot load module pilight_raw" (auch bei ..._temp, ..._dimmer, usw)
Was muss ich jetzt machen damit er die Module lädt?
Vorab Danke
Es fehlen sicherlich die Pakete libjson-perl oder libswitch-perl
Wow Tausend Dank.
Jetzt habe ich nur noch 1Problem.
Wenn ich ein Reboot durchführe muss ich mich immer anmelden und pilight-daemon starten.
Gibt es dafür eine Lösung ? Die Ansätze mit rc anpassen hatte ich schon versucht.
Vielleicht die config.json ?
Hat jemand eine Beispiel config.json ?
Danke
Ich hab es geschafft.
Nachdem ich jedes mal die config.json überschrieben hab um den "Port": 5000 zu setzen (hat nicht funktioniert).
Jetzt habe ich pilight neu installiert, config geöffnet und einen unnötigen Datensatz in Settings gelöscht und dafür "Port":5000 gesetzt.
Was soll ich sagen, es funktioniert:-)
Moin Moin!
Gibt es in pilight für FHEM die Möglichkeit mehrere Protokolle / i-/u-/s-Werte für einen Switch zu definieren?
In Pilight-GUI geht das:
"Lampe1": {
"protocol": [ "elro_400_switch", "intertechno_old", "pollin" ],
"id": [{
"systemcode": 0,
"unitcode": 1
},
{
"id": 0,
"unit": 0
},
{
"systemcode": 13,
"unitcode": 10
}],
"state": "off"
},
führt in pilight dazu, dass, unabhängig von der benutzten Fernbedienung (3 Stück), die Schaltbefehle für Lampe1 erkannt und der Status in der GUI von pilight aktualisiert wird.
Grüße
Hallo.
Nein, dass ist aktuell nicht möglich.
Man bekommt das aber sicherlich mit einer structure aus den drei einzelnen Schaltern und drei notify hin.
Schaltet die Hardware wirklich bei allen drei Fernbedienungen oder meinst du nur die Lampe in der pilight-gui?
Ja - sind selbstlernende Schalter, habe 3 FB angelernt (2xWandschalter und 1x Schlüsselanhänger).
3 FHEM-GUI-Schalter definieren, die sich irgendwie gegenseitig informieren ergibt halt drei "Lampen" in der GUI oder kann man 2 der so definierten Schalter ausblenden?
Wahrscheinlich eine RTFM-Frage...
Grüße
Klar in hiddenroom.
Benötigst in einem Raum dann nur die structure.
Hallo an Alle!
Ich habe ein Problem mit dem Modul pilight_raw. Wenn ich versuche einen RAW-Code an meine Steckdosen zu senden, stürzt das Modul pilight_ctrl ab. Es reagiert dann nicht mehr bis man FHEM neu startet oder auf reset drückt.
Es sind solche anlernbaren Steckdosen von Toom. Über die Kommandozeile kann ich die Steckdosen problemlos mit folgendem Befehl starten:
sudo pilight-send -p raw --code="480 1040 980 540 980 540 480 1040 1020 500 980 540 480 1040 480 1060 480 1040 980 540 480 1040 980 560 480 1040 980 540 980 560 980 560 480 1040 480 1060 480 1040 980 560 980 540 980 560 480 1040 480 1140 360 2280 340 1160 1100 420 1100 420 340 1200 1080 420 1100 420 360 1160 360 1180 340 1160 1100 420 360 1160 1100 420 340 1160 1100 420 1100 420 1100 440 340 1180 340 1180 360 1160 1100 420 1220 300 1100 420 340 1180 340 1260 360 2300 340 1160 1100 420 1100 420 340 1180 1100 420 1100 420 340 1160 340 1180 340 1160 1100 420 340 1180 1100 440 340 1180 1100 420 1100 420 1100 420 360 1160 340 1160 340 1180 1100 420 1100 420 1100 420 360 1160 360 1260 360 2300 340 1160 1100 420 1100 420 360 1180 1100 420 1100 420 340 1160 360 1180 340 1160 1100 420 360 1160 1100 440 340 1180 1100 420 1100 420 1100 420 360 1160 360 1160 360 1180 1100 420 1100 420 1100 420 360 1160 360 1260 360 2300 340 1160 1100 420 1100 420 360 1180 1100 420 1100 420 360 1180 340 1180 360 1160 1100 420 360 1160 1100 420 360 1160 1100 420 1100 420 1100 420 360 1180 340 1160 360 1160 1100 420 1100 420 1100 420 340 1180 340 1260 2980 7060"
Ich denke der RAW-Code ist zu lang, allerdings bin ich noch nicht so weit mit der Materie vertraut daraus ein Protokoll zu entwickeln.
Kann mir jemand helfen? Im Log steht übrigens meistens nichts brauchbares drin, ausser das es beim Senden zu einem Timeout kam.
Über Ideen oder Lösungsvorschläge würde ich mich freuen! Danke :)
PS: Wenn alle Stricke reißen schreibe ich ein Skript, allerdings würde ich das ganze lieber innerhalb von FHEM abwickeln.
Hallo Tonno,
ja es lag an der Länge des Codes.
Habe es gefixed. Sollte ab morgen gehen.
Super Sache :D
Danke vielmals! Werde es morgen ausprobieren.
Das Modul funktioniert nun. Interessant an der Sache ist: Ich habe heute die Restlichen Frequenzen der Fernbedienung gesucht und festgestellt, dass der erste Code total überfrachtet ist, die Dose damit aber trotzdem schaltet.
Neuer RAW-Code
460 1060 980 560 980 580 440 1100 1000 480 980 580 960 560 980 580 440 1060 460 1060 980 580 940 580 960 540 980 560 960 580 500 1060 420 1080 960 540 960 600 460 1080 960 520 960 560 460 1060 500 1060 2960 7080
Die Steckdose schaltet sowohl mit der langen Variante, als auch mit der kurzen??
Servus zusammen.
Ich wollte mal fragen ob einer von euch Erfahrung mit der Tablet-UI in Zusammenhang mit Pilight hat. Ich dachte ich frag erstmal hier nach. Also über den Browser kann ich alles ganz normal schalten, jedoch aus der Tablet -UI passiert mal gar nichts.
Hab das ganze so in der Index.html eingebunden
<div data-type="switch" class="cell"
data-device="Schlafzimmer"
data-get-on="on.*"
data-get-off="off"></div>
Gibt es da noch irgendeinen kniff den ich vergessen habe, oder reicht es nicht einfach den Namen einzutragen?
Falls das nicht hierher gehört. Sry.
----------------------------------------------------------------------------------------------------------------------------------------------
Hab selber die Lösung gefunden, und vll hilft es ja mal irgend jemandem.
Es muss einfach nur der Teil:
data-get-on="on.*"
data-get-off="off"
entfernt werden, und schon kann geschaltet werden.
MfG
Hallo erstmal! Wie kann ich denn einen pilight_switch definieren, wenn das Protokoll (daycom) id, systemcode und unit erwartet? Vielleicht stelle ich mich auch zu doof an, aber ich habe es nicht hinbekommen :( Die Usage für den pilight-send lautet -i -s -u. Im Modul pilight (98_pilight.pm) habe ich es nach kleiner Anpassung im Modul hinbekommen. Würde aber gerne das pilight Modul von Risiko verwenden.
Hallo Tatsu,
ich habe das Protokoll 'daycom' aufgenommen. Sollte ab morgen gehen.
Es war leider etwas aufwendiger, da es das erste Protokoll beim Switch mit drei ID's (id, systemcode, unit) ist.
Demzufolge müssen bei der Definition des Switches drei Nummern übergeben werden
define <name> pilight_switch daycom <id> <unit> <systemcode>
define <name> pilight_switch daycom 1 2 3
Achtung:
Bei allen anderen Protokollen bspw. pollin bleibt alles beim Alten:
Hier ist id==systemcode und unit==unitcode
Zitat von: Risiko am 28 März 2016, 15:34:35
Hallo Tatsu,
ich habe das Protokoll 'daycom' aufgenommen. Sollte ab morgen gehen.
Hallo Risiko,
wow das ging ja fix, vielen vielen Dank schon mal! :-) Ich teste es morgen dann und ergänze dann anschließend ob es geklappt hat.
Update 05.04.: funktioniert, DANKE!!! :-)
Danke & Gruß
Tatsu
Hallo zusammen,
finde ich super, was ihr hier macht. Ich bin neu und falle vielleicht gerade schon das erste Mal blöde auf: aber kann mir bitte jemand sagen, wo ich diese Module denn bekommen kann?
Danke im Voraus.
Edit: Ja, falle blöde auf. Habe die Antwort hier weiter vorne gefunden. Danke.
Sind in fhem eingebaut. Nutzbar durch Definition von pilight in fhem. Schaue mal hier von Anfang an durch den thread. ;-)
Gesendet von meinem SM-T560 mit Tapatalk
Danke, sash.sc für Deine Antwort.
Hatte es selber schon gesehen, siehe oben.
Trotzdem vielen Dank für Deine Antwort.
Als Neuling einen Überblick zu bekommen, ist halt nicht so leicht.
Kein Problem. Habe ja auch mal mit fhem angefangen!
Gesendet von meinem SM-T560 mit Tapatalk
2016.03.31 17:48:07 3: pilight: Unknown code PISWITCH,rev2_switch,F0,0,off, help me!
2016.03.31 17:48:07 3: pilight: Unknown code PISWITCH,clarus_switch,F0,0,off, help me!
2016.03.31 17:48:15 3: pilight: Unknown code PISWITCH,rev2_switch,F0,0,off, help me!
2016.03.31 17:48:15 3: pilight: Unknown code PISWITCH,clarus_switch,F0,0,off, help me!
Habe aber ein neues Problem (s. o).
Das was ich im Thread gefunden habe, ist folgendes:
"Scheinbar empfängst du mehr, (Stichwort Nachbar, Störungen,etc) wofür du aber kein Device definiert hast.
Dafür gibt es aktuell nur die Ignore-Liste (Attribut ignore)."
Ignore gibt es anscheinend so nicht, ich habe folgendes probiert:
"define pilight pilight_ctrl localhost:5000
attr pilight ignoreProtocol rev2_switch"
Die Fehlermeldungen für rev2_switch bleiben. Im übrigen habe ich noch gar nichts weiter definiert. Wie bekomme ich diese Meldungen weg, sie müllen natürlich das Log-File zu.
Danke für alle Antworten.
Habe das so bei mir in die cfg eingetragen.
attr pilight ignoreProtocol conrad_rsl_switch:6,clarus_switch:*,rev*:*
Usw. Klappt eigentlich ganz gut
Gesendet von meinem SM-T560 mit Tapatalk
Hallo
ignoreProtocol *
Steht schon x-mal im Thread ;)
Hallo sash.sc, hallo Risiko,
dir sash.sc vielen Dank für Deine Antowort und dir Risiko für Deine Arbeit an den Modulen. Das ich ignoreProtocol durchaus ausprobiert habe, muss ich zu meiner Ehrenrettung aber erwähnen (in meiner Frage).
sah.sc: Kannst Du mir bitte Deine Fehlermeldung schicken, damit ich daraus den richtigen Eintrag für mich generieren kann?
Vielen Dank Euch beiden.
In meinem Beispiel oben ist es die "geistermeldung" Conrad_rsl_switch mit der Adresse 6. Wenn du im Terminal den Befehl pilight-receive eingibst, dann bekommst du ja alles was empfangen wird. Das was du einen möchtest baust du in das ignore ein. Habe im Moment pilight bei mir in fhem abgeschaltet! ;-)
Gruß Sascha
Hallo Alda,
du kannst es so machen wie Sascha es beschreibt.
Wenn du alle Protokolle und ID's kennst und die entsprechenden Geräte in FHEM definiert hast kannst du alle sonstigen Meldungen mit
ignoreProtocol *
einfach(er) ignorieren.
Hallo sash.sc, hallo Risiko,
ich wollte mich noch einmal bedanken, bin ein Stück weitergekommen. Leider ist dann mein Rechner kaputt gegangen, deswegen erst jetzt nocheinmal die Rückmeldung.
Hi Risiko,
ich hatte mal den Vorschlag gemacht, dass man "repeats" zumindest im pilight_switch Modul mit einarbeitet. Ich habe für mich selber mal nur "IOWrite($hash, $msg);" 3x hintereinander im Code eingefügt. Damit reagieren die trägeren Steckdosen schon mal um einiges besser.
Ich kenne die Architektur des Moduls zu wenig, aber was hältst du davon einfach ein Attribute "repeats" einzufügen und dann x-mal IOWrite($hash, $msg) durchzuführen? Das wäre eine sehr einfach Lösung. Aber wie gesagt, die Architektur kennst du besser und weißt daher ob das so sinnvoll ist. Nur mal ein Vorschlag von meiner Seite.
Gruß,
Dominik
Hallo Dominik,
es spricht auf den ersten Blick erstmal nichts dagegen, obwohl man das sicherlich mit einem at oder DOIF hinbekommen könnte.
Sehe es auch eher bei den einzelnen Device-Modulen (pilight_switch, pilight_dimmer) als in pilight_ctrl. So kann man es bei Problemgeräten explizit setzen.
Ist es evtl. sinnvoll zwischen den NxSenden ein Delay zu haben!?
Werde es dieses WE aber nicht schaffen. Sollte aber in den nächsten 14 Tagen mgl. sein.
Risiko
Hi Risiko,
wenn ich den Code in pilight_ctrl richtig verstanden habe, entsteht automatisch immer ein Delay von 0.5s, oder? Das wäre eigentlich vollkommen ausreichend. Wäre echt super, wenn du das mit aufnehmen könntest.
Gruß,
Dominik
Hallo habe ein Problem
Wenn ich eine Lampe über fhem einschalte und über Fernbedienung dann wieder ausschalte wird in fhem der Status nicht aktualisiert obwohl fhem das Signal der Fernbedienung empfängt.
Ich weiß das das mal funktioniert hat
Woran kann es liegen? Im angehängten Auszug aus dem event Monitor das Einschalten via fhem und ausschalten via fernbedienung.
2016-04-24 10:25:01 pilight Kugel on
2016-04-24 10:25:01 pilight_ctrl Funken rcv_raw: {"origin":"sender","protocol":"impuls","message":{"systemcode":10,"programcode":8,"state":"on"},"repeat":1,"uuid":"0000-b8-27-eb-7f74db"}
2016-04-24 10:25:01 pilight_ctrl Funken UNKNOWNCODE PISWITCH,impuls,10,8,on,10
2016-04-24 10:25:07 pilight_ctrl Funken rcv_raw: {"message":{"systemcode":10,"programcode":8,"state":"off"},"origin":"receiver","protocol":"impuls","uuid":"0000-b8-27-eb-7f74db","repeats":1}
2016-04-24 10:25:07 pilight_ctrl Funken UNKNOWNCODE PISWITCH,impuls,10,8,off,10
2016-04-24 10:25:07 pilight_ctrl Funken rcv_raw: {"message":{"systemcode":10,"programcode":24,"state":"off"},"origin":"receiver","protocol":"impuls","uuid":"0000-b8-27-eb-7f74db","repeats":2}
Zusätzlich kann ich meine Funk Steckdosen nicht mehr über den toggle Befehl schalten das ging vor ein paar Wochen auch noch.
Hallo Tueftler1983,
wie sieht denn dein define aus?
Und mach mal bitte ein list vom Device.
Zitat von: dominik am 23 April 2016, 15:22:08
Hi Risiko,
wenn ich den Code in pilight_ctrl richtig verstanden habe, entsteht automatisch immer ein Delay von 0.5s, oder? Das wäre eigentlich vollkommen ausreichend. Wäre echt super, wenn du das mit aufnehmen könntest.
Nein nicht zwangsläufig. Die 0.5s kommen nur zum tragen, wenn bereits ein Befehl bearbeitet wird.
Zitat von: dominik am 23 April 2016, 12:23:11
Hi Risiko,
ich hatte mal den Vorschlag gemacht, dass man "repeats" zumindest im pilight_switch Modul mit einarbeitet. Ich habe für mich selber mal nur "IOWrite($hash, $msg);" 3x hintereinander im Code eingefügt. Damit reagieren die trägeren Steckdosen schon mal um einiges besser.
Gruß,
Dominik
So. Habe ein Attribute "sendCount" eingebaut. Damit kann man steuern, wie oft der Befehl gesendet wird. Default ist 1:
Was ist ein list? Und die Bilder zeigen einmal das Modul und die Stehlampe
Zitat von: Risiko am 24 April 2016, 19:03:43
So. Habe ein Attribute "sendCount" eingebaut. Damit kann man steuern, wie oft der Befehl gesendet wird. Default ist 1:
Cool, danke für die schnelle Implementierung!
Meinst du das?
Mea Culpa, Mea Culpa, Mea maxima Culpa!
Ich habe als ich meinen Pi neu aufsetzen mußte eine fhem.cfg eingespielt die ich letztes Jahr gesichert hatte allerdings hatte ich da dein Modul noch nicht in verwendung.
Jetzt wo ich in der Definition pilight_switch und nicht nur pilight stehen habe und als attr noch IODev Funken hinzugefügt habe geht auch Toggle und die Status Änderung wenn ich Viel Fernbedienung schalte.
Nochmals tut mir leid!!!
Die Verwendung des "falschen" Moduls hatte ich mir schon gedacht ;)
Schön, dass es jetzt wieder funktioniert.
Nächsten Monat kommt meine Wetterstation mit Regenmesser, Wind Richtung und Geschwindigkeitsmessung, und 3 Temperatur und hydro sensoren. Hoffe das ich diese eingebunden bekomme.
Zitat von: Tueftler1983 am 25 April 2016, 21:05:01
Nächsten Monat kommt meine Wetterstation mit Regenmesser, Wind Richtung und Geschwindigkeitsmessung, und 3 Temperatur und hydro sensoren. Hoffe das ich diese eingebunden bekomme.
Welche und wo bestellt? 8)
Zitat von: Tueftler1983 am 25 April 2016, 21:05:01
Nächsten Monat kommt meine Wetterstation mit Regenmesser, Wind Richtung und Geschwindigkeitsmessung, und 3 Temperatur und hydro sensoren. Hoffe das ich diese eingebunden bekomme.
Wenn die Wetterstation von pilight unterstützt wird, dann bekommen wir das auch hin.
Aktuell wird nur eine Temperatur, Windgeschwindigkeit, Windrichtung, Druck und Feuchtigkeit unterstützt.
Nabend zusammen,
Ich bräuchte mal eure Hilfe.
Ich würde gerne weitere Steckdosen in FHEM integrieren, scheitere aber schon daran, das ganze in pilight zu integrieren.
Die Steckdosen sind über das "Drehrad" auf B2 eingestellt
Über pilight- receive erhalte ich folgendes
{
"message": {
"id": 1,
"unit": 1,
"state": "up"
},
"origin": "receiver",
"protocol": "arctech_screen_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 1
}
{
"message": {
"id": 1,
"unit": 1,
"state": "on"
},
"origin": "receiver",
"protocol": "arctech_switch_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 1
}
{
"message": {
"id": 1,
"unit": 1,
"state": "up"
},
"origin": "receiver",
"protocol": "arctech_screen_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 2
}
{
"message": {
"id": 1,
"unit": 1,
"state": "on"
},
"origin": "receiver",
"protocol": "arctech_switch_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 2
}
{
"message": {
"id": 1,
"unit": 1,
"state": "up"
},
"origin": "receiver",
"protocol": "arctech_screen_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 3
}
{
"message": {
"id": 1,
"unit": 1,
"state": "on"
},
"origin": "receiver",
"protocol": "arctech_switch_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 3
}
{
"message": {
"id": 23,
"unit": 7,
"state": "up"
},
"origin": "receiver",
"protocol": "arctech_screen_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 1
}
{
"message": {
"systemcode": 10,
"unitcode": 22,
"state": "on"
},
"origin": "receiver",
"protocol": "elro_800_switch",
"uuid": "0000-74-da-38-6f2745",
"repeats": 1
}
{
"message": {
"id": 19,
"unit": 5,
"state": "on"
},
"origin": "receiver",
"protocol": "arctech_switch_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 1
}
{
"message": {
"id": 20074,
"unit": -1
},
"origin": "receiver",
"protocol": "beamish_switch",
"uuid": "0000-74-da-38-6f2745",
"repeats": 1
}
{
"message": {
"id": 6,
"unit": 5,
"state": "off"
},
"origin": "receiver",
"protocol": "conrad_rsl_switch",
"uuid": "0000-74-da-38-6f2745",
"repeats": 1
}
{
"message": {
"id": "D7",
"unit": 16,
"state": "off"
},
"origin": "receiver",
"protocol": "clarus_switch",
"uuid": "0000-74-da-38-6f2745",
"repeats": 1
}
Was genau muss ich in der /etc/pilight/config.json eintragen?
Alles was ich bisher versucht habe,
"Switch4": {
"protocol": [ "arctech_switch_old" ],
"id": [{
"id": 1,
"unit": 1
}],
"state": "off"
führte immer dazu, dass ich Pilight nicht mehr starten konnte.
Bin für Tipps dankbar.
Grüße
Zitat von: Esjaycc am 06 Mai 2016, 22:16:16
Was genau muss ich in der /etc/pilight/config.json eintragen?
Nur den Port (Achtung nicht Web-Port). Steht aber auch schon öfters hier im Thread z.B. https://forum.fhem.de/index.php/topic,34632.msg402083.html#msg402083
Viel Erfolg
Zitat von: Risiko am 07 Mai 2016, 11:47:10
Nur den Port (Achtung nicht Web-Port). Steht aber auch schon öfters hier im Thread z.B. https://forum.fhem.de/index.php/topic,34632.msg402083.html#msg402083
Viel Erfolg
Ok,hab mich wohl ein bisschen komisch ausgedrückt.Sorry..Ich habe schon 3 Steckdosen in fhem eingebunden,und wollte jetzt um 3 erweitern..
Wenn ich jetzt über ssh
pilight-receiveeingebe, und auf der Fernbedienung die Steckdose einschalte,erhalte ich
{
"message": {
"id": 1,
"unit": 1,
"state": "up"
},
"origin": "receiver",
"protocol": "arctech_screen_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 1
}
{
"message": {
"id": 1,
"unit": 1,
"state": "on"
},
"origin": "receiver",
"protocol": "arctech_switch_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 1
}
{
"message": {
"id": 1,
"unit": 1,
"state": "up"
},
"origin": "receiver",
"protocol": "arctech_screen_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 2
}
{
"message": {
"id": 1,
"unit": 1,
"state": "on"
},
"origin": "receiver",
"protocol": "arctech_switch_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 2
}
{
"message": {
"id": 1,
"unit": 1,
"state": "up"
},
"origin": "receiver",
"protocol": "arctech_screen_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 3
}
{
"message": {
"id": 1,
"unit": 1,
"state": "on"
},
"origin": "receiver",
"protocol": "arctech_switch_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 3
}
{
"message": {
"id": 23,
"unit": 7,
"state": "up"
},
"origin": "receiver",
"protocol": "arctech_screen_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 1
}
{
"message": {
"systemcode": 10,
"unitcode": 22,
"state": "on"
},
"origin": "receiver",
"protocol": "elro_800_switch",
"uuid": "0000-74-da-38-6f2745",
"repeats": 1
}
{
"message": {
"id": 19,
"unit": 5,
"state": "on"
},
"origin": "receiver",
"protocol": "arctech_switch_old",
"uuid": "0000-74-da-38-6f2745",
"repeats": 1
}
{
"message": {
"id": 20074,
"unit": -1
},
"origin": "receiver",
"protocol": "beamish_switch",
"uuid": "0000-74-da-38-6f2745",
"repeats": 1
}
{
"message": {
"id": 6,
"unit": 5,
"state": "off"
},
"origin": "receiver",
"protocol": "conrad_rsl_switch",
"uuid": "0000-74-da-38-6f2745",
"repeats": 1
}
{
"message": {
"id": "D7",
"unit": 16,
"state": "off"
},
"origin": "receiver",
"protocol": "clarus_switch",
"uuid": "0000-74-da-38-6f2745",
"repeats": Mir geht es jetzt ersteinmal darum,welche dieser informationen ich in der json unter devices wie einrichten muss.
Hinterher das ganze in Fhem einzubinden ist ja dann nicht das Problem,allerdings muss es ja erstmal über pilight schaltbar sein..Ich weiß,dass hat nicht direkt mit dem Modul zu tun,aber vll kann mir ja hier trotzdem geholfen werden..
Gruß
Muss nicht zwingend über pilight schaltbar sein. Du musst nur eine verbindung über den Port 5000 haben und dann mit dem Protokoll arctec_switch_old in fhem konfigurieren!
Gruß Sascha
Also in der pilight config.json mußt du nur eine Zeile mit : port: 5000
Einfügen dann in FHEM
pilight.Ctrl definieren, danach kannst du im eventmonitor die Signale sehen die über pilight.ctrl empfangen werden.
Und dann kannst du über define test pilight_switch arctec_switch_old xx x
Deine funksteckdose anlegen.
In pilight selber brauchst du nix außer den Port 5000 definieren.
Zitat von: Tueftler1983 am 08 Mai 2016, 11:09:37
Also in der pilight config.json mußt du nur eine Zeile mit : port: 5000
Einfügen dann in FHEM
pilight.Ctrl definieren, danach kannst du im eventmonitor die Signale sehen die über pilight.ctrl empfangen werden.
Und dann kannst du über define test pilight_switch arctec_switch_old xx x
Deine funksteckdose anlegen.
In pilight selber brauchst du nix außer den Port 5000 definieren.
Ahh ok jetzt verstehe ich was gemeint ist. Wusste gar nicht, dass das funktioniert. Danke
Ich habe jetzt folgendes im Eventmonitor gesehen.
2016-05-08 12:05:46 pilight_ctrl WZ rcv_raw: {"message":{"id":20,"unit":0,"state":"off"},"origin":"receiver","protocol":"arctech_switch_old","uuid":"0000-74-da-38-6f2745","repeats":1}
2016-05-08 12:05:46 pilight_ctrl WZ UNKNOWNCODE PISWITCH,kaku_switch_old,20,0,off
2016-05-08 12:05:48 pilight_ctrl WZ rcv_raw: {"message":{"id":1,"unit":1,"state":"up"},"origin":"receiver","protocol":"arctech_screen_old","uuid":"0000-74-da-38-6f2745","repeats":1}
2016-05-08 12:05:48 pilight_ctrl WZ UNKNOWNCODE PISCREEN,kaku_screen_old,1,1,up
2016-05-08 12:05:48 pilight_ctrl WZ rcv_raw: {"message":{"id":1,"unit":1,"state":"on"},"origin":"receiver","protocol":"arctech_switch_old","uuid":"0000-74-da-38-6f2745","repeats":1}
2016-05-08 12:05:48 pilight_ctrl WZ UNKNOWNCODE PISWITCH,kaku_switch_old,1,1,on
2016-05-08 12:07:30 pilight_ctrl WZ rcv_raw: {"message":{"id":15,"unit":13,"state":"up"},"origin":"receiver","protocol":"arctech_screen_old","uuid":"0000-74-da-38-6f2745","repeats":1}
2016-05-08 12:07:30 pilight_ctrl WZ UNKNOWNCODE PISCREEN,kaku_screen_old,15,13,up
2016-05-08 12:07:30 pilight_ctrl WZ rcv_raw: {"message":{"id":2,"unit":1,"state":"on"},"origin":"receiver","protocol":"arctech_switch_old","uuid":"0000-74-da-38-6f2745","repeats":1}
2016-05-08 12:07:30 pilight_ctrl WZ UNKNOWNCODE PISWITCH,kaku_switch_old,2,1,on
2016-05-08 12:08:24 pilight_ctrl WZ rcv_raw: {"message":{"id":31,"unit":15,"state":"up"},"origin":"receiver","protocol":"arctech_screen_old","uuid":"0000-74-da-38-6f2745","repeats":1}
2016-05-08 12:08:24 pilight_ctrl WZ UNKNOWNCODE PISCREEN,kaku_screen_old,31,15,up
2016-05-08 12:08:24 pilight_ctrl WZ rcv_raw: {"message":{"id":14,"unit":15,"state":"on"},"origin":"receiver","protocol":"arctech_switch_old","uuid":"0000-74-da-38-6f2745","repeats":1}
2016-05-08 12:08:24 pilight_ctrl WZ UNKNOWNCODE PISWITCH,kaku_switch_old,14,15,onHabe dann per define test pilight_switch arctec_switch_old 1 1 das ganze definiert, aber die Steckdose schaltet nicht. Hab ich noch i-was übersehen, oder fehlt noch was?
Hallo habe hier noch eine elro ab400s funksteckdose gefunden aber bekomme diese nicht angesprochen.
Dip schalter stehen auf 1000010000
Sollte also mit define Pumpe pilight_switch elro_400 1 1 funktionieren, tut es aber leider nicht.
Hat noch jemand diese Steckdosen am laufen?
Zitat von: Esjaycc am 08 Mai 2016, 12:17:25
Ahh ok jetzt verstehe ich was gemeint ist. Wusste gar nicht, dass das funktioniert. Danke
Ich habe jetzt folgendes im Eventmonitor gesehen.
2016-05-08 12:05:46 pilight_ctrl WZ rcv_raw: {"message":{"id":20,"unit":0,"state":"off"},"origin":"receiver","protocol":"arctech_switch_old","uuid":"0000-74-da-38-6f2745","repeats":1}
2016-05-08 12:05:46 pilight_ctrl WZ UNKNOWNCODE PISWITCH,kaku_switch_old,20,0,off
2016-05-08 12:05:48 pilight_ctrl WZ rcv_raw: {"message":{"id":1,"unit":1,"state":"up"},"origin":"receiver","protocol":"arctech_screen_old","uuid":"0000-74-da-38-6f2745","repeats":1}
2016-05-08 12:05:48 pilight_ctrl WZ UNKNOWNCODE PISCREEN,kaku_screen_old,1,1,up
2016-05-08 12:05:48 pilight_ctrl WZ rcv_raw: {"message":{"id":1,"unit":1,"state":"on"},"origin":"receiver","protocol":"arctech_switch_old","uuid":"0000-74-da-38-6f2745","repeats":1}
2016-05-08 12:05:48 pilight_ctrl WZ UNKNOWNCODE PISWITCH,kaku_switch_old,1,1,on
2016-05-08 12:07:30 pilight_ctrl WZ rcv_raw: {"message":{"id":15,"unit":13,"state":"up"},"origin":"receiver","protocol":"arctech_screen_old","uuid":"0000-74-da-38-6f2745","repeats":1}
2016-05-08 12:07:30 pilight_ctrl WZ UNKNOWNCODE PISCREEN,kaku_screen_old,15,13,up
2016-05-08 12:07:30 pilight_ctrl WZ rcv_raw: {"message":{"id":2,"unit":1,"state":"on"},"origin":"receiver","protocol":"arctech_switch_old","uuid":"0000-74-da-38-6f2745","repeats":1}
2016-05-08 12:07:30 pilight_ctrl WZ UNKNOWNCODE PISWITCH,kaku_switch_old,2,1,on
2016-05-08 12:08:24 pilight_ctrl WZ rcv_raw: {"message":{"id":31,"unit":15,"state":"up"},"origin":"receiver","protocol":"arctech_screen_old","uuid":"0000-74-da-38-6f2745","repeats":1}
2016-05-08 12:08:24 pilight_ctrl WZ UNKNOWNCODE PISCREEN,kaku_screen_old,31,15,up
2016-05-08 12:08:24 pilight_ctrl WZ rcv_raw: {"message":{"id":14,"unit":15,"state":"on"},"origin":"receiver","protocol":"arctech_switch_old","uuid":"0000-74-da-38-6f2745","repeats":1}
2016-05-08 12:08:24 pilight_ctrl WZ UNKNOWNCODE PISWITCH,kaku_switch_old,14,15,on
Habe dann per define test pilight_switch arctec_switch_old 1 1 das ganze definiert, aber die Steckdose schaltet nicht. Hab ich noch i-was übersehen, oder fehlt noch was?
Versuche mal define test pilight_switch arctech_screen_old 15 13
Und teste das mal
Oder
define test pilight_switch kaku_switch_old 14 15
Lass uns wissen wenn es klappt
Zitat von: Tueftler1983 am 08 Mai 2016, 21:40:21
Versuche mal define test pilight_switch arctech_screen_old 15 13
Und teste das mal
Oder
define test pilight_switch kaku_switch_old 14 15
Lass uns wissen wenn es klappt
Klappt leider beides nicht. Hab mal ins logfile geguckt, und der spuckt folgendes aus
2016.05.08 21:52:22 3: WZ: Unknown code PISWITCH,elro_400_switch,8,5,on,8, help me!
2016.05.08 21:52:22 3: WZ: Unknown code PISWITCH,elro_800_contact,29,11,opened,29, help me!
2016.05.08 21:52:22 3: WZ: Unknown code PISWITCH,elro_800_switch,29,11,on,29, help me!
2016.05.08 21:52:22 3: WZ: Unknown code PISWITCH,daycom,6,2,on,13825, help me!
2016.05.08 21:52:22 3: WZ(Parse): unknown protocol -> ev1527
2016.05.08 21:54:30 3: WZ: Unknown code PISCREEN,kaku_screen_old,17,0,up, help me!
2016.05.08 21:54:30 3: WZ: Unknown code PISWITCH,kaku_switch_old,17,0,on, help me!
2016.05.08 21:56:35 3: WZ: Unknown code PISWITCH,conrad_rsl_switch,6,5,off, help me!
2016.05.08 21:57:18 4: WZ(Write): RCV (pilight_switch) -> test,off
2016.05.08 21:57:18 4: WZ(Write): {"action":"send","code":{"protocol":["kaku_switch_old"],"id":14,"unit":15,"off":1}}
2016.05.08 21:57:18 5: WZ(SendNonBlocking): queue size 1
2016.05.08 21:57:18 5: WZ(Send): {"action":"send","code":{"protocol":["kaku_switch_old"],"id":14,"unit":15,"off":1}}
2016.05.08 21:57:18 4: WZ(Send): RCV -> {"status":"success"}
2016.05.08 21:57:18 4: WZ(SendDone): message successfully send
2016.05.08 21:57:19 5: WZ(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch_old","message":{"id":14,"unit":15,"state":"off"},"repeat":1,"uuid":"0000-74-da-38-6f2745"}
2016.05.08 21:57:19 4: WZ(Dispatch): PISWITCH,kaku_switch_old,14,15,off
2016.05.08 21:57:19 5: WZ dispatch PISWITCH,kaku_switch_old,14,15,off
2016.05.08 21:57:19 4: pilight_switch_Parse: RCV -> PISWITCH,kaku_switch_old,14,15,off
2016.05.08 21:57:20 4: WZ(Write): RCV (pilight_switch) -> test,on
2016.05.08 21:57:20 4: WZ(Write): {"action":"send","code":{"protocol":["kaku_switch_old"],"id":14,"unit":15,"on":1}}
2016.05.08 21:57:20 5: WZ(SendNonBlocking): queue size 1
2016.05.08 21:57:20 5: WZ(Send): {"action":"send","code":{"protocol":["kaku_switch_old"],"id":14,"unit":15,"on":1}}
2016.05.08 21:57:20 4: WZ(Send): RCV -> {"status":"success"}
2016.05.08 21:57:20 4: WZ(SendDone): message successfully send
2016.05.08 21:57:20 5: WZ(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch_old","message":{"id":14,"unit":15,"state":"on"},"repeat":1,"uuid":"0000-74-da-38-6f2745"}
2016.05.08 21:57:20 4: WZ(Dispatch): PISWITCH,kaku_switch_old,14,15,on
2016.05.08 21:57:20 5: WZ dispatch PISWITCH,kaku_switch_old,14,15,on
2016.05.08 21:57:20 4: pilight_switch_Parse: RCV -> PISWITCH,kaku_switch_old,14,15,on
2016.05.08 21:57:21 4: WZ(Write): RCV (pilight_switch) -> test,off
2016.05.08 21:57:21 4: WZ(Write): {"action":"send","code":{"protocol":["kaku_switch_old"],"id":14,"unit":15,"off":1}}
2016.05.08 21:57:21 5: WZ(SendNonBlocking): queue size 1
2016.05.08 21:57:21 5: WZ(Send): {"action":"send","code":{"protocol":["kaku_switch_old"],"id":14,"unit":15,"off":1}}
2016.05.08 21:57:21 4: WZ(Send): RCV -> {"status":"success"}
2016.05.08 21:57:21 4: WZ(SendDone): message successfully send
2016.05.08 21:57:22 5: WZ(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch_old","message":{"id":14,"unit":15,"state":"off"},"repeat":1,"uuid":"0000-74-da-38-6f2745"}
2016.05.08 21:57:22 4: WZ(Dispatch): PISWITCH,kaku_switch_old,14,15,off
2016.05.08 21:57:22 5: WZ dispatch PISWITCH,kaku_switch_old,14,15,off
2016.05.08 21:57:22 4: pilight_switch_Parse: RCV -> PISWITCH,kaku_switch_old,14,15,off
2016.05.08 21:57:23 4: WZ(Write): RCV (pilight_switch) -> test,on
2016.05.08 21:57:23 4: WZ(Write): {"action":"send","code":{"protocol":["kaku_switch_old"],"id":14,"unit":15,"on":1}}
2016.05.08 21:57:23 5: WZ(SendNonBlocking): queue size 1
2016.05.08 21:57:23 5: WZ(Send): {"action":"send","code":{"protocol":["kaku_switch_old"],"id":14,"unit":15,"on":1}}
2016.05.08 21:57:23 4: WZ(Send): RCV -> {"status":"success"}
2016.05.08 21:57:23 4: WZ(SendDone): message successfully send
2016.05.08 21:57:23 5: WZ(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch_old","message":{"id":14,"unit":15,"state":"on"},"repeat":1,"uuid":"0000-74-da-38-6f2745"}
2016.05.08 21:57:23 4: WZ(Dispatch): PISWITCH,kaku_switch_old,14,15,on
2016.05.08 21:57:23 5: WZ dispatch PISWITCH,kaku_switch_old,14,15,on
2016.05.08 21:57:23 4: pilight_switch_Parse: RCV -> PISWITCH,kaku_switch_old,14,15,on
2016.05.08 21:57:24 4: WZ(Write): RCV (pilight_switch) -> test,off
2016.05.08 21:57:24 4: WZ(Write): {"action":"send","code":{"protocol":["kaku_switch_old"],"id":14,"unit":15,"off":1}}
2016.05.08 21:57:24 5: WZ(SendNonBlocking): queue size 1
2016.05.08 21:57:24 5: WZ(Send): {"action":"send","code":{"protocol":["kaku_switch_old"],"id":14,"unit":15,"off":1}}
2016.05.08 21:57:24 4: WZ(Send): RCV -> {"status":"success"}
2016.05.08 21:57:24 4: WZ(SendDone): message successfully send
2016.05.08 21:57:25 5: WZ(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch_old","message":{"id":14,"unit":15,"state":"off"},"repeat":1,"uuid":"0000-74-da-38-6f2745"}
2016.05.08 21:57:25 4: WZ(Dispatch): PISWITCH,kaku_switch_old,14,15,off
2016.05.08 21:57:25 5: WZ dispatch PISWITCH,kaku_switch_old,14,15,off
2016.05.08 21:57:25 4: pilight_switch_Parse: RCV -> PISWITCH,kaku_switch_old,14,15,off
2016.05.08 21:57:26 4: WZ(Write): RCV (pilight_switch) -> test,on
2016.05.08 21:57:26 4: WZ(Write): {"action":"send","code":{"protocol":["kaku_switch_old"],"id":14,"unit":15,"on":1}}
2016.05.08 21:57:26 5: WZ(SendNonBlocking): queue size 1
2016.05.08 21:57:26 5: WZ(Send): {"action":"send","code":{"protocol":["kaku_switch_old"],"id":14,"unit":15,"on":1}}
2016.05.08 21:57:26 4: WZ(Send): RCV -> {"status":"success"}
2016.05.08 21:57:26 4: WZ(SendDone): message successfully send
2016.05.08 21:57:26 5: WZ(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch_old","message":{"id":14,"unit":15,"state":"on"},"repeat":1,"uuid":"0000-74-da-38-6f2745"}
2016.05.08 21:57:26 4: WZ(Dispatch): PISWITCH,kaku_switch_old,14,15,on
2016.05.08 21:57:26 5: WZ dispatch PISWITCH,kaku_switch_old,14,15,on
2016.05.08 21:57:26 4: pilight_switch_Parse: RCV -> PISWITCH,kaku_switch_old,14,15,on
Werde wohl noch etwas rumprobieren müssen. Aber danke für deine Hilfe
Grüße
Hallo Esjaycc,
es tauchen mehrere Protokolle mit unterschiedlichen Id's im Log auf.
Was da nun genau richtig ist oder nur falsch von pilight erkannt wird (Rauschen - davon scheinst du viel haben), kann ich natürlich auch nicht sagen. Folgende Konstellationen kommen häufiger vor:
kaku_switch_old,17,0
kaku_switch_old,2,1
kaku_switch_old,1,1
elro_400_switch,8,5
Hallo zusammen,
Ich habe einen Temperatur und Luftfeuchte Sensor Model THGR228N
Leider bekomme ich keine Daten, der Sensor funktioniert da auf der Wetterstation Daten angezeigt werden.
Mit pilight-debug bekomme ich zwar Daten aber nichts wiederholbares.
Kann mir jemand sagen wie ich an das Protokoll komme um den Sensor aus zu lesen?
Für einen RFXtrx433 USB tranceiver gibt es eine integration. Vielleicht kann die helfen es zu integrieren!?
Okay es gibt eine Version 6 von pilight in der das Oregon Protokoll integriert ist.
Deine Module funktionieren auch mit dieser Version aber ich bekomme den Sensor in FHEM nicht integriert bzw definiert.
Im FHEM Event monitor steht folgendes:
016-05-28 01:34:02 pilight_ctrl Funken rcv_raw: {"message":{"device_id":7456,"id":1,"unit":110,"battery":0,"temperature":22.00,"humidity":38.00},"origin":"receiver","protocol":"oregon_21","uuid":"0000-00-00-56-7f74db","repeats":1}
Habe es mit define Temp1 pilight_temp oregon_21 7456
versucht aber bekomme keine werte
#### Anhang der pilight version
######## Nachtrag pilight beispiel config
"devices": {
"TempSensTHGR122N": {
"protocol": [ "oregon_21" ],
"id": [{
"device_id": 7456,
"id": 3,
"unit": 155
}],
"battery": 0,
"humidity": 10.00,
"temperature": 10.00
}
},
"rules": { },
"gui": {
"TempSensTHGR122N": {
"name": "Living_Room",
"group": [ "Weather" ],
"media": [ "all" ],
"temperature-decimals": 2,
"humidity-decimals": 1,
"show-battery": 1,
"show-temperature": 1,
"show-humidity": 1
}
},
hallo, ich habe das mit den arctech:koku nicht richtige verstanden zum empfangen . ich will ein taster einbinden und bin sehr neu im diesem gebiet . wie mach ich das jetzt genau. ich benutze arctech Steckdosen und wie gesagt will ein taster einbinden ..
besten dank im voraus.
Hallo bekomme es in fhem nicht hin den Temperatur-Luftfeuchte Sensor anzubinden.
Für die Definition in pilight ist folgendes für die ID:
"id": [{
"device_id": 7456,
"id": 3,
"unit": 155
device ID ist um was für einen Sensor handeld,
Id ist der Kanal 1-3
unit ist die Adresse die sich bei jedem Batterie Wechsel ändert
Auszug aus pilight debug
[ Jun 01 10:17:08:26857] pilight-daemon: DEBUG: broadcasted: {"origin":"update","type":3,"devices":["TempSensTHGR122N"],"values":{"timestamp":1464776228,"battery":1,"humidity":47.00,"temperature":22.80}}
[ Jun 01 10:17:08:29866] pilight-daemon: DEBUG: socket write succeeded: {"message":{"device_id":7456,"id":2,"unit":132,"battery":1,"temperature":22.80,"humidity":47.00},"origin":"receiver","protocol":"oregon_21","uuid":"0000-b8-27-eb-7f74db","repeats":3}
[ Jun 01 10:17:08:42571] pilight-daemon: DEBUG: socket write succeeded: {"message":{"device_id":7456,"id":2,"unit":132,"battery":1,"temperature":22.80,"humidity":47.00},"origin":"receiver","protocol":"oregon_21","uuid":"0000-b8-27-eb-7f74db","repeats":3}
[ Jun 01 10:17:08:43536] pilight-daemon: DEBUG: broadcasted: {"message":{"device_id":7456,"id":2,"unit":132,"battery":1,"temperature":22.80,"humidity":47.00},"origin":"receiver","protocol":"oregon_21","uuid":"0000-b8-27-eb-7f74db","repeats":3}
Siehst du Möglichkeiten ihn zu integrieren?
Hier noch ein Auszug aus dem FHEM eventmonitor:
2016-06-02 19:49:57 pilight_ctrl Funken UNKNOWNCODE PISWITCH,clarus_switch,F14,30,off
2016-06-02 19:50:38 pilight_ctrl Funken rcv_raw: {"message":{"device_id":7456,"id":2,"unit":132,"battery":1,"temperature":22.70,"humidity":42.00},"origin":"receiver","protocol":"oregon_21","uuid":"0000-b8-27-eb-7f74db","repeats":1}
2016-06-02 19:51:19 pilight_ctrl Funken rcv_raw: {"message":{"device_id":7456,"id":2,"unit":132,"battery":1,"temperature":22.70,"humidity":42.00},"origin":"receiver","protocol":"oregon_21","uuid":"0000-b8-27-eb-7f74db","repeats":1}
2016-06-02 19:52:00 pilight_ctrl Funken rcv_raw: {"message":{"device_id":7456,"id":2,"unit":132,"battery":1,"temperature":22.70,"humidity":42.00},"origin":"receiver","protocol":"oregon_21","uuid":"0000-b8-27-eb-7f74db","repeats":1}
Würde mich freuen wenn es klappt.
@Tueftler1983
Habe das "oregon_21"-Protokoll mit aufgenommen.
Steht ab morgen zum testen bereit.
@neidersun
Was meist du genau? Es wenig Information zum helfen.
Super,
Vielen lieben dank hoffe die ganzen Infos haben geholfen.
Finde es klasse das du deine Module so pflegst
Wie muss der Sensor denn Dan konfiguriert bzw definiert werden?
Hallo
define <name> pilight_temp oregon_21 2
sollte gehen.
In deinen Postings sehe ich aber auch Widersprüche. Mal ist Id 2 mal 3
Ja sorry hatte das _21 vergessen..... manchmal sieht man den Wald vor lauter Bäumen nicht mehr
@Risiko
Hallo,ich will einen funkschalter einbinden, so das ich mit einem funkschalter alles schalten kann und es in Fhem aktualisiert wird.
Ich kann in fhem schalten aber weil ich den schalter nicht einbinden kann schaltet Fhem nicht um.
das pilight-receive geht nicht und weis nicht wie ich das emfangen verstehn soll..
ich benutze arctech steckdosen .
:-[ :-[
@neidersun
Was bedeutet pilight-receive funktioniert nicht? Wie ist die Ausgabe von pilight-receive wenn du eine taste drückst?
Hast du schonmal versucht was pilight-daemon -D ausgibt?
Kannst du mit der Fernbedienung denn die Steckdosen Schalten? Denn wenn du die Steckdosen mit Fernbedienung und auch FHEM schalten kannst sollte pilight_switch auch mitbekommen wenn du mit der Fernbedienung schaltest.
Der Empfänger ist aber richtig am Raspberry angeschlossen?
@ Tueftler1983
Hallo, pilight-receive fuktioniert bei der ausgabe nur leider nicht bei fhem.
bei dir ausgaber pilight-daemon -D zeigt er mir das: pilight-daemon requires root privileges in order to run.
Mit der ferbedinung kann ich schalten zeigt nur nichts in fhem an. ich habe es auch grade mit (define test pilight_switch kaku_switch 14663666 13) nur leider funktioniert da uberhaubt nichts.
ich mache es mit (define test pilight kaku_switch 14663666 13) da fukitioniert es zwar aber in fhem wird nicht umgeschaltet.
:-[ :-[
Da haben wir schon den fehler!
pilight ist nicht pilight_switch worum es hier im thed geht!
Hast du pilight_Ctrl konfiguriert? define Funken pilight_ctrl 127.0.0.1:5000 6.0
Hast du in pilight in der config.json den Port 5000 eingetragen?
ja. der port 5000 ist eingetragen :)
muss ich einfach (define Funken pilight_ctrl 127.0.0.1:5000 6.0) eintragen und das warst schon oder was?? :o
Ja fast damit ist das steuermodul für pilight_switch definiert.
Und dann deine Steckdosen mit :
define test pilight_switch kaku_switch 14663666 13
Dann kannst du in fhem schalten und fhem bekommt mit wenn du via Fernbedienung schaltest.
Melde dich wenn klappt oder nicht klappt
P.s. wenn das Steuer Modul definiert ist solltest du im EventMonitor von FHEM sehen wenn du eine taste deiner Fernbedienung drückst
aha ok, habe ich mal gleich getsetet schalten tut es jetzt aber leider schaltet der icon nicht und steht nur defined.
denn habe ich es definiert und geht auch nicht mit Extend devStateIcon defination.
muss man da eine andere defination einstellen???
Zitat von: neidersun am 07 Juni 2016, 01:21:25
aha ok, habe ich mal gleich getsetet schalten tut es jetzt aber leider schaltet der icon nicht und steht nur defined.
denn habe ich es definiert und geht auch nicht mit Extend devStateIcon defination.
muss man da eine andere defination einstellen???
Ich habe bzw hatte pilight benutzt. Meine Definition sah so aus.
define pilight pilight_ctrl localhost:5000
Dann oben genannte Definition deiner Steckdose. Dann sollte es laufen. Aber wie gesagt, port:5000 in der json von pilight eintragen.
Gruß Sascha
Gesendet von meinem SM-T560 mit Tapatalk
Was steht denn im eventmonitor in FHEM wenn du eine taste der Fernbedienung drückst?
@Tueftler1983
also wenn ich jetzt richtig liege ist es das alles:
oder gibt es noch ein anderen eventmonitor???
Internals
API
6.0
CFGFN
DEF
127.0.0.1:5000 6.0
DeviceName
127.0.0.1:5000
FD
15
NAME
Funken
NR
140
NTFY_ORDER
50-Funken
PARTIAL
RETRY_INTERVAL
60
STATE
connected
TYPE
pilight_ctrl
Readings
rcv_raw
{"origin":"sender","protocol":"arctech_switch","message":{"id":23051982,"unit":7,"state":"on"},"repeat":1,"uuid":"0000-b8-27-eb-da70ca"}
2016-06-07 12:00:00
state
connected
2016-06-07 01:15:24
@sash.sc
Habe ich gestetet kommt das selbe, wenn ich (define test pilight kaku_switch 14663666 13) mache zeigt fhem auch kein icon und schlaten das icon nicht.
Warum es eigentlich so viele unterschitliche difination gibt. ???
Habe ic
@ neidersun
Er meint den EventMonitor, den du links unten auswählen kannst, wenn du dich auf deinen FHEM Server aufschaltest.Sprich unter den Raumbezeichnungen ect. Wenn ich es richtig im Kopf habe, ist er in der Box, unter "Select Style".
Den auswählen, anschließend mit deiner Fernbedienung ganz nah an den Empfänger, und dann mal den Ein Knopf drücken.
ok sorry.
also da kommt nichts wenn ich die taste drücke auser meine und andere pca301 fuckdosen.
2016-06-07 15:22:07 Global global UNDEFINED PCA301_03F14B PCA301 03F14B 03
2016-06-07 15:22:09 PCA301 PCA301_0384F5 power: 2.6
2016-06-07 15:22:13 Global global UNDEFINED PCA301_0387FE PCA301 0387FE 02
2016-06-07 15:22:26 Global global UNDEFINED PCA301_039104 PCA301 039104 01
2016-06-07 15:22:38 Global global UNDEFINED PCA301_03F14B PCA301 03F14B 03
2016-06-07 15:22:41 PCA301 PCA301_0384F5 power: 2.5
2016-06-07 15:22:43 Global global UNDEFINED PCA301_0387FE PCA301 0387FE 02
2016-06-07 15:22:58 Global global UNDEFINED PCA301_039104 PCA301 039104 01
2016-06-07 15:23:09 Global global UNDEFINED PCA301_03F14B PCA301 03F14B 03
2016-06-07 15:23:14 PCA301 PCA301_0384F5 power: 2.6
2016-06-07 15:23:14 Global global UNDEFINED PCA301_0387FE PCA301 0387FE 02
2016-06-07 15:23:14 PCA301 PCA301_0384F5 power: 2.8
2016-06-07 15:23:28 Global global UNDEFINED PCA301_039104 PCA301 039104 01
2016-06-07 15:23:40 Global global UNDEFINED PCA301_03F14B PCA301 03F14B 03
2016-06-07 15:23:46 PCA301 PCA301_0384F5 power: 2.5
2016-06-07 15:23:50 Global global UNDEFINED PCA301_0387FE PCA301 0387FE 02
2016-06-07 15:23:58 Global global UNDEFINED PCA301_039104 PCA301 039104 01
Du hast aber an deinem Raspberry sowohl ein sende alsauch ein Empfangs Modul angeschlossen oder?
Angeschlossen wie im Bild im anhang.
Wenn ja solltest du im eventmonitor auch sehen wenn du eine taste drückst.
ja habe ich und jetzt kam was, anscheint war da kapel nicht richtig verbunden..
2016-06-07 15:39:35 pilight_ctrl Funken rcv_raw: {"message":{"id":14663666,"unit":13,"state":"up"},"origin":"receiver","protocol":"arctech_screen","uuid":"0000-b8-27-eb-da70ca","repeats":1}
2016-06-07 15:39:35 pilight_ctrl Funken UNKNOWNCODE PISCREEN,arctech_screen,14663666,13,up
2016-06-07 15:39:35 pilight_ctrl Funken rcv_raw: {"message":{"id":14663666,"unit":13,"state":"on"},"origin":"receiver","protocol":"arctech_switch","uuid":"0000-b8-27-eb-da70ca","repeats":1}
Dann versuch mal
define Steckdose pilight_switch arctech_switch 14663666 13
Und guck ob du damit schalten kannst und sich der Status ändert wenn du mit der Fernbedienung schaltest
8) jetzt geht es... :)
ich habe auf dem foto gesehen das die antenne ja 30-35 cm sein muss und teste ich mal gleich.
der emfang ist nicht so brauchent, grade mal 1m.
Ich kann diese Sender und Empfänger nur empfehlen https://www.amazon.de/gp/aw/d/B00OLI93IC/ref=mp_s_a_1_1?qid=1465310574&sr=1-1&pi=SY200_QL40&keywords=433+mhz+superregeneration&dpPl=1&dpID=41EWO4DasNL&ref=plSrch
Habe damit die ganze Wohnung abgedeckt
Eine Antenne von 17cm reicht...... ;-)
Gesendet von meinem SM-T560 mit Tapatalk
@Tueftler1983
den emfänger habe ich,der ist bestimmt kaput.
oder die antenne
werde ich auf 17cm umendern. ;)
Ich habe auch Klingeldraht auf 17,3 cm geschnitten und als Antenne angelötet
mh, geht alles nicht. ich habe jetzt ein neuen bestellt.
denn habe wir jetzt schon mal eine hörde beseitigt und jetzt kommt homebridge dran aber kommt ja hier nicht rein.
danke danke danke noch mal. ;) :)
Danke, dass ihr neidersun unterstützt habt.
Am meisten bringt meiner Meinung nach der Filter und eine ordentliche Antenne.
https://forum.fhem.de/index.php/topic,34632.msg287771.html#msg287771
@Risiko
Hallo :-)
wie hast du denn die antenne angebracht da ist dich nur ein anschluss für die antenne an dem emfänger oder sender.
ok , ist bestellt 8)
Steht doch hier im Thread - einfach mal suchen.....
https://forum.fhem.de/index.php/topic,34632.msg308418/topicseen.html#msg308418
Wenn ich da nochmal nachfragen darf. Du hast eine Antenne und Daten den Sender und den Empfänger angeschlossen?
Wußte garnicht das das geht ich dachte ich brauche eine für den Sender und eine für den Empfänger
und wieder ein problem ich kann ich fhem mit der config nicht mehr schalten.
Ich kann einfach in fhem nicht mher schalten.
Ferbidinung schaltet zeigt auch an das geschaltet wurde . :-[
wie beschiben habe ich alles so gemacht wie ihr es geschriben habt:
also so:
define Funken pilight_ctrl 127.0.0.1:5000 6.0
Dann so:
define Flur_Licht pilight_switch arctech_switch 14663666 14
Sieht erstmal korrekt aus.
Was steht denn im Log?
Zitat von: Tueftler1983 am 08 Juni 2016, 22:28:48
Wenn ich da nochmal nachfragen darf. Du hast eine Antenne und Daten den Sender und den Empfänger angeschlossen?
Wußte garnicht das das geht ich dachte ich brauche eine für den Sender und eine für den Empfänger
Ja. Weiß, dass es nicht ganz sauber ist - funktioniert aber. Schon über ein Jahr.
Zitat von: Risiko am 09 Juni 2016, 16:47:32
Sieht erstmal korrekt aus.
Was steht denn im Log?
Das steht im log wenn ich fernbedinung schalte, wenn ich in fhem schalte kommt nichts.
2016.06.09 16:55:41 3: Funken: Unknown code PISCREEN,arctech_screen,14663666,14,down, help me!
2016.06.09 16:55:41 3: Funken: Unknown code PISCREEN,arctech_screen,14663666,14,down, help me!
2016.06.09 16:55:41 3: Funken: Unknown code PISCREEN,arctech_screen,14663666,14,down, help me!
2016.06.09 16:55:49 3: Funken: Unknown code PISCREEN,arctech_screen,14663666,14,up, help me!
2016.06.09 16:55:49 3: Funken: Unknown code PISCREEN,arctech_screen,14663666,14,up, help me!
2016.06.09 16:55:49 3: Funken: Unknown code PISCREEN,arctech_screen,14663666,14,up, help me!
ich habe noch mal log gelöcht und denn neugestartet.
da kommt das:
2016.06.09 17:01:52 1: Including fhem.cfg
2016.06.09 17:01:52 3: telnetPort: port 7072 opened
2016.06.09 17:01:52 3: WEB: port 8083 opened
2016.06.09 17:01:52 3: WEBphone: port 8084 opened
2016.06.09 17:01:52 3: WEBtablet: port 8085 opened
2016.06.09 17:01:52 2: eventTypes: loaded 90 events from ./log/eventTypes.txt
2016.06.09 17:01:53 3: Opening CUL_0 device /dev/ttyACM0
2016.06.09 17:01:53 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.06.09 17:01:53 3: CUL_0 device opened
2016.06.09 17:01:53 3: CUL_0: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
2016.06.09 17:01:53 2: Switched CUL_0 rfmode to MAX
2016.06.09 17:01:53 3: CUL_MAX_Check: Detected firmware version 154 of the CUL-compatible IODev
2016.06.09 17:01:56 1: PERL WARNING: splice on reference is experimental at ./FHEM/10_pilight_ctrl.pm line 197.
2016.06.09 17:01:56 1: PERL WARNING: splice on reference is experimental at ./FHEM/10_pilight_ctrl.pm line 565.
2016.06.09 17:01:56 1: PERL WARNING: Subroutine BC_searchTelnet redefined at ./FHEM/Blocking.pm line 33.
2016.06.09 17:01:56 1: PERL WARNING: Subroutine BlockingCall redefined at ./FHEM/Blocking.pm line 68.
2016.06.09 17:01:56 1: PERL WARNING: Subroutine BlockingInformParent redefined at ./FHEM/Blocking.pm line 107.
2016.06.09 17:01:56 1: PERL WARNING: Subroutine BlockingKill redefined at ./FHEM/Blocking.pm line 157.
2016.06.09 17:01:56 1: PERL WARNING: Subroutine BlockingExit redefined at ./FHEM/Blocking.pm line 185.
2016.06.09 17:01:56 3: Opening Funken device 127.0.0.1:5000
2016.06.09 17:01:56 3: Funken device opened
2016.06.09 17:01:56 1: Including ./log/fhem.save
2016.06.09 17:01:56 1: usb create starting
2016.06.09 17:01:57 3: Probing CUL device /dev/ttyAMA0
2016.06.09 17:01:57 3: Can't open /dev/ttyAMA0: Permission denied
2016.06.09 17:01:57 1: usb create end
2016.06.09 17:01:57 0: Featurelevel: 5.7
2016.06.09 17:01:57 0: Server started with 20 defined entities (fhem.pl:11611/2016-06-04 perl:5.020002 os:linux user:fhem pid:1608)
hatt keine eine ide was das sein kann.. :-[
Zitat
und wieder ein problem ich kann ich fhem mit der config nicht mehr schalten.
Ich kann einfach in fhem nicht mher schalten.
Ferbidinung schaltet zeigt auch an das geschaltet wurde . :-[
wie beschiben habe ich alles so gemacht wie ihr es geschriben habt:
also so:
Code: [Auswählen]
define Funken pilight_ctrl 127.0.0.1:5000 6.0
Dann so:
Code: [Auswählen]
define Flur_Licht pilight_switch arctech_switch 14663666 14
Füge mal noch folgendes ein.
attr Flur_Licht IODev Funken
Das Funken ist ja deine Namensdefinition für pilight_ctrl.
Gruß Sascha
Gesendet von meinem SM-T560 mit Tapatalk
@sash.sc
so wie das auschaut macht das fhem schon fon alleine.
hab es auch mal versucht,geht auch nicht. :-[
[quote name="Risiko" post=460258 timestamp=1465483652]
Sieht erstmal korrekt aus.
Was steht denn im Log?
[/quote]
Das steht im log wenn ich fernbedinung schalte, wenn ich in fhem schalte kommt nichts.
Code: [Auswählen]
2016.06.09 16:55:41 3: Funken: Unknown code PISCREEN,arctech_screen,14663666,14,down, help me!<br />2016.06.09 16:55:41 3: Funken: Unknown code PISCREEN,arctech_screen,14663666,14,down, help me!<br />2016.06.09 16:55:41 3: Funken: Unknown code PISCREEN,arctech_screen,14663666,14,down, help me!<br />2016.06.09 16:55:49 3: Funken: Unknown code PISCREEN,arctech_screen,14663666,14,up, help me!<br />2016.06.09 16:55:49 3: Funken: Unknown code PISCREEN,arctech_screen,14663666,14,up, help me!<br />2016.06.09 16:55:49 3: Funken: Unknown code PISCREEN,arctech_screen,14663666,14,up, help me!
In deinem log steht auch was von 'arctech_screen' und nicht von 'arctech_switch'.
Der Switch ist eine schalter bzw. Steckdose.
Der Screen ist wahrscheinlich ein Rollo oder Jalousie oder was ähnliches.
In deinem log steht auch zum Schluss was von up und down.
Dies solltest du in deiner Definition beachten!
Also artech_switch in artech_screen umändern und zum Schluss noch up und /oder down hinzufügen.
Gruß Sascha
Gesendet von meinem SM-T560 mit Tapatalk
Ja genau.
Ist die Hardware wirklich ein Schalter? Es kommen nur Meldungen mit arctech_screen und keine mit arctech_switch!!!!
Setze mal bitte verbose von pilight_ctrl auf 4 und schalte noch mal in FHEM und mit der Fernbedienung.
Was steht alles im Log?
Wenn es sich eher um ein Jalousie bzw. Dimmer mit up\down handelt, dann nimm pilight_dimmer.
ja. das ist eine fernbedinung.
ich habe es jetzt hinbekommen.
und swar so:
define Funken pilight_ctrl 127.0.0.1:5000 6.0
attr Funken brands kaku:arctech,arctech:kaku
define Flur_Licht pilight_switch kaku_switch 14663666 14
ascheint ein fehler in arctech_switch...
ist nicht beöse gemeine aber die anleitung ist sehr schwher zu verstehen.
ich habe sie bestimmt 50 mal gelsen und denn sah ich noch mal genau hin und sah arctech:kaku und dachte mir denn irgentwan dreh doch mal den spieß um und suchte brands und fand ich unter Funken.
:)
Für alle die das brauchen: bitte :)
Hallo ist eigentlich das Protokoll secudo_smoke_sensor auch eingebunden? So könnte man seine Funk RauchMelder in fhem integrieren
Nein noch nicht.
Kann es mir nach meinem Urlaub mal ansehen.
Dazu musst du mir mal zeigen, was pilight-receive oder Log ausgibt.
Hallo im fhem event Monitor steht
15 15:37:27 pilight_ctrl Funken rcv_raw: {"message":{"id":0,"state":"alarm"},"origin":"receiver","protocol":"secudo_smoke_sensor","uuid":"0000-b8-27-eb-7f74db","repeats":1}
Und pilight-receive gibt das aus
{
"message": {
"id": 0,
"state": "alarm"
},
"origin": "receiver",
"protocol": "secudo_smoke_sensor",
"uuid": "0000-b8-27-eb-7f74db",
"repeats": 1
}
{
"message": {
"id": 0,
"state": "alarm"
},
"origin": "receiver",
"protocol": "secudo_smoke_sensor",
"uuid": "0000-b8-27-eb-7f74db",
"repeats": 1
}
Würde mich freuen wenn es klappt
Was kann state für Werte annehmen?
Nur Alarm das wird dann alle x Sekunden gesendet. Man muss dann quasi in fhem den Status nach x Sekunden zurück setzen.
Das wird sicherlich auf ein neues Modul "30_pilight_smokedector" oder so hinaus laufen.
Kennst du noch weitere Protokolle dafür und könntest du bitte mal was zur Hardware sagen. Evtl. besorg ich mir mal so ein Teil zum testen.
Weitere Protokolle kenne ich nicht.
Meine Rauchender sind von Elro/Flamingo Modell: FA21RF.
Mehr Infos habe ich derzeit nicht
Hallo,
ich hoffe ich bin im richtigen Thread.
Mit Perl 5.24 ist es nicht mehr möglich splice auf Skalare anzuwenden. Ich bekomme daher folgende Fehlermeldungen:
016.06.20 19:15:38 1: reload: Error:Modul 10_pilight_ctrl deactivated:
Experimental splice on scalar is now forbidden at ./FHEM/10_pilight_ctrl.pm line 197, near "})"
Experimental splice on scalar is now forbidden at ./FHEM/10_pilight_ctrl.pm line 565, near "})"
Leider reichen meine perl-Kenntnisse nur soweit, dass ich den Fehler finde aber bei weitem nicht zu einem Patch. Ich hoffe der Bug-Report hier an dieser Stelle ist in Ordnung. Wenn nicht, kann der Post gerne verschoben werden.
Viele Grüße,
martin
Ja, dass ist hier richtig.
Werde es aber erst in ca. 2-3 Wochen schaffen, mir das anzusehen.
Hallo Risiko,
vielen Dank für dein Modul :) Dieses funktionierte bei mir wunderbar mit Pilight v7 aus den Debian Stable-Repositories, denn das Logfile von Pilight führte diese auf. Leider funktioniert diese Version von Pilight nicht auf meinem Banana Pi und der Entwickler hat mich auf die Rewrite Branch (künftige v8.0) verwiesen. Mit dieser kann ich erfolgreich meine 433 MHz Geräte schalten, jedoch scheint dein Modul leider nicht korrekt mit Pilight kommunizieren zu können. Das pilight_ctrl Device verbindet sich erst, doch nach wenigen Sekunden verliert pilight_ctrl die Verbindung, Kommandos kommen nicht bei pilight an. Kann ich dir irgendwie helfen dies zu debuggen?
2016.06.25 13:30:37 3: Opening System.Control.Pilight device 127.0.0.1:5000
2016.06.25 13:30:37 3: System.Control.Pilight device opened
2016.06.25 13:30:49 1: 127.0.0.1:5000 disconnected, waiting to reappear (System.Control.Pilight)
Liebe Grüße,
Alex
Hallo Alex,
mit pilight v8 habe ich selbst noch nicht getestet. Wenn die Jungs die API nicht geändert haben, dann sollte alles funktionieren.
Konnte aber zur v8 (speziell zur API) noch keine Infos finden.
Du kannst ja mal das verbose von pilight_ctrl auf 4 oder 5 setzen.
Zitat von: inw am 20 Juni 2016, 20:58:57
Mit Perl 5.24 ist es nicht mehr möglich splice auf Skalare anzuwenden. Ich bekomme daher folgende Fehlermeldungen:
016.06.20 19:15:38 1: reload: Error:Modul 10_pilight_ctrl deactivated:
Experimental splice on scalar is now forbidden at ./FHEM/10_pilight_ctrl.pm line 197, near "})"
Experimental splice on scalar is now forbidden at ./FHEM/10_pilight_ctrl.pm line 565, near "})"
Gefixed. Ab morgen per Update.
Zitat von: Tueftler1983 am 17 Juni 2016, 14:37:31
Nur Alarm das wird dann alle x Sekunden gesendet. Man muss dann quasi in fhem den Status nach x Sekunden zurück setzen.
Hallo Tueftler1983,
anbei eine erste Testversion für das neue Modul pilight_smoke. Konnte es selbst wegen fehlender Hardware nicht testen.
define my_smoke_sensor pilight_smoke secudo_smoke_sensor 0
Mit dem Attribut 'resetTime' kann man die Zeit in Sek. einstellen, wenn der State wieder zurück gesetzt (aktuell none) werden soll.
Ist das Ganze eigentlich schon in die Developer-Version (zukünftige 8.0) geflossen oder geht das nur mit dem branch 'elro_fa20fr'?
Zitat von: Risiko am 28 Juni 2016, 11:23:47
Hallo Alex,
mit pilight v8 habe ich selbst noch nicht getestet. Wenn die Jungs die API nicht geändert haben, dann sollte alles funktionieren.
Konnte aber zur v8 (speziell zur API) noch keine Infos finden.
Du kannst ja mal das verbose von pilight_ctrl auf 4 oder 5 setzen.
Halo Risiko,
danke für deinen Vorschlag. Über etwaige API-Änderungen weiß ich leider auch nicht viel, wenn ich das jedoch richtig verstanden habe gab es dort seit etwa 2 Jahren keine Änderungen (https://github.com/pilight/pilight/tree/rewrite/clients) mehr. Dennoch funktioniert es leider nicht (mehr) bei mir. Ich hatte vorher die Debian Stable v7 via APT-GET drauf und damit klappte die Kommunikation. Mit der selbstkompilierten Version mittels Rewrite Code hingegen scheint die Kommunikation abzubrechen bzw. gar nicht erst zu funktionieren. Ich habe dir mal ein FHEM Log angehängt, welches den Aufbau der Verbindung zum Pilight Daemon (nach "set reset") und den anschließenden automatischen Konnektivitätsverlust (ohne weiteres zutun) dokumentiert:
2016.06.28 19:06:44 5 : System.Control.Pilight(TryConnect): disconnected
2016.06.28 19:06:44 3 : Opening System.Control.Pilight device 127.0.0.1:5000
2016.06.28 19:06:44 5 : System.Control.Pilight(DoInit): opened
2016.06.28 19:06:44 5 : System.Control.Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2016.06.28 19:06:44 4 : System.Control.Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2016.06.28 19:06:44 5 : SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2016.06.28 19:06:44 3 : System.Control.Pilight device opened
2016.06.28 19:06:45 5 : System.Control.Pilight(Check): opened
2016.06.28 19:06:46 5 : System.Control.Pilight(Check): opened
2016.06.28 19:06:47 5 : System.Control.Pilight(Check): opened
2016.06.28 19:06:47 5 : System.Control.Pilight(DoInit): opened
2016.06.28 19:06:47 5 : System.Control.Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2016.06.28 19:06:47 4 : System.Control.Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2016.06.28 19:06:47 5 : SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2016.06.28 19:06:48 5 : System.Control.Pilight(Check): opened
2016.06.28 19:06:49 5 : System.Control.Pilight(Check): opened
2016.06.28 19:06:50 5 : System.Control.Pilight(Check): opened
2016.06.28 19:06:50 5 : System.Control.Pilight(DoInit): opened
2016.06.28 19:06:50 5 : System.Control.Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2016.06.28 19:06:50 4 : System.Control.Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2016.06.28 19:06:50 5 : SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2016.06.28 19:06:51 5 : System.Control.Pilight(Check): opened
2016.06.28 19:06:52 5 : System.Control.Pilight(Check): opened
2016.06.28 19:06:53 5 : System.Control.Pilight(Close): close DevIo
2016.06.28 19:06:53 5 : System.Control.Pilight(TryConnect): closed
2016.06.28 19:06:53 3 : Opening System.Control.Pilight device 127.0.0.1:5000
2016.06.28 19:06:53 5 : System.Control.Pilight(DoInit): opened
2016.06.28 19:06:53 5 : System.Control.Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2016.06.28 19:06:53 4 : System.Control.Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2016.06.28 19:06:53 5 : SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2016.06.28 19:06:53 3 : System.Control.Pilight device opened
2016-06-28 19:06:53 pilight_ctrl System.Control.Pilight reset
2016.06.28 19:06:54 5 : System.Control.Pilight(Check): opened
2016.06.28 19:06:55 5 : System.Control.Pilight(Check): opened
2016.06.28 19:06:56 5 : System.Control.Pilight(Check): opened
2016.06.28 19:06:56 5 : System.Control.Pilight(DoInit): opened
2016.06.28 19:06:56 5 : System.Control.Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2016.06.28 19:06:56 4 : System.Control.Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2016.06.28 19:06:56 5 : SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2016.06.28 19:06:57 5 : System.Control.Pilight(Check): opened
2016.06.28 19:06:58 5 : System.Control.Pilight(Check): opened
2016.06.28 19:06:59 5 : System.Control.Pilight(Check): opened
2016.06.28 19:06:59 5 : System.Control.Pilight(DoInit): opened
2016.06.28 19:06:59 5 : System.Control.Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2016.06.28 19:06:59 4 : System.Control.Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2016.06.28 19:06:59 5 : SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2016.06.28 19:07:00 5 : System.Control.Pilight(Check): opened
2016.06.28 19:07:01 5 : System.Control.Pilight(Check): opened
2016.06.28 19:07:02 5 : System.Control.Pilight(Check): opened
2016.06.28 19:07:02 5 : System.Control.Pilight(DoInit): opened
2016.06.28 19:07:02 5 : System.Control.Pilight(DoInit): send {"action":"identify","options":{"receiver":1},"media":"all"}
2016.06.28 19:07:02 4 : System.Control.Pilight(SimpleWrite): snd -> {"action":"identify","options":{"receiver":1},"media":"all"}
2016.06.28 19:07:02 5 : SW: 7b22616374696f6e223a226964656e74696679222c226f7074696f6e73223a7b227265636569766572223a317d2c226d65646961223a22616c6c227d0a
2016.06.28 19:07:03 5 : System.Control.Pilight(Check): opened
2016.06.28 19:07:04 5 : System.Control.Pilight(Check): opened
2016.06.28 19:07:05 5 : System.Control.Pilight(Check): opened
2016.06.28 19:07:05 4 : System.Control.Pilight(Check): Could not connect to pilight-daemon 127.0.0.1:5000 - maybe wrong api version or port
2016.06.28 19:07:05 1 : 127.0.0.1:5000 disconnected, waiting to reappear (System.Control.Pilight)
Liebe Grüße,
Alex
Hallo Alex,
mir scheint es so, als wenn bei Verwendung des speziellen Branches 'rewrite' was mit dem pilight-daemon nicht i.O. ist. Es kommt keine Antwort auf das Senden der Identifikation.
Ist wirklich der Port 5000 konfiguriert? Nicht mit Web-Port verwechseln!!!!! Ggf. mal mit telnet versuchen.
Könntest du nicht den branch 'development' verwenden\versuchen?
Hinweis: Der Code-Link ist nicht die API-Schnittstelle in pilight, sondern nur Testclients.
Hallo Risiko,
die selbe Vermutung hatte ich auch. Ich habe deshalb im Pilight Forum eine Anfrage (https://forum.pilight.org/showthread.php?tid=2371) erstellt.
Eine Verbindung mit Telnet klappt übrigens bei mir, auch wenn ich nach dem "Connected" to nicht mehr weiß welche Befehle verfügbar sind, der Server scheint auf keine Befehle zu antworten.
Die development branch habe ich bisher nicht ausprobiert, da mir curlymo empfohlen hatte die rewrite branch zu verwenden. Ich warte erstmal ab was er schreibt, bevor ich mich wieder ans wilde kompilieren begebe - das war leider recht aufwendig.
Zitat von: Risiko am 28 Juni 2016, 19:30:55
Hinweis: Der Code-Link ist nicht die API-Schnittstelle in pilight, sondern nur Testclients.
Sorry, das habe ich nicht verstanden. Meinst du, dass dein Modul nicht über API-Zugriffe auf Pilight zugreift sondern...?
Doch schon. Es wird die Json-API verwendet.
Der Link, den du hier angegeben hast, bezieht sich aber auf beispielhafte Client Implementierungen in unterschiedlichen Sprachen und nicht auf die Implementierung der API in pilight selbst.
Danke, das leuchtet mir ein, jetzt verstehe ich auch deinen ersten Satz. Da stand ich ein wenig auf dem Schlauch :)
Zur offiziellen API-Implementierung konnte ich leider nicht viel finden, bzw. die GitHub Code-Suche war nicht sonderlich ergiebig. Das wird jedoch auch eher an meiner minimalen C-Erfahrung liegen. Die "Testclients" in anderen Sprachen sind jedoch offiziell und ich gehe davon aus, dass er diese angepasst hätte wenn es Änderungen an der API gegeben hätte.
Es gab nun auch eine Antwort auf meinen Foren-Thread im Pilight Forum, welche unseren Verdacht stützt, dass das Problem in der API-Implementierung zu suchen ist.
Einstweilen, vielen Dank für deine kompetente Hilfe!
... und eine Antwort erhalten. Tatsächlich gibt es nun eine REST-API für Pilight in den neueren Versionen. Habe dies gerade mit der rewrite Branch erfolgreich verwenden können. Kurz beschrieben wird diese hier: https://www.pilight.org/nightly/
Ich habe ein wenig rumprobiert und man muss aufpassen welche Bezeichnung für Systemcode / ID bzw. Unitcode / Unit man verwendet. Das richtet sich wie bisher nach dem Protocol (pilight-send -p PROTOCOL --help) und funktioniert auch nur mit den ausgeschriebenen Optionen (bspw. nicht "t=1" sondern "on=1"!)
Hier ein Beispiel, welches bei mir funktioniert:
curl "http://127.0.0.1:5001/send?protocol=brennenstuhl&on=1&systemcode=5&unitcode=5"
curl "http://127.0.0.1:5001/send?protocol=brennenstuhl&off=1&systemcode=5&unitcode=5"
Wie man direkt erkennen kann läuft das alles auch nur noch über den Webserver-Port. Für pilight_ctrl bedeutet dies vmtl leider, dass hier einiges umgebaut werden muss.
Ok. Erstmal danke für die Infos.
Ich finde es total Schei......, dass die Jungs schon wieder die API ändern.
Kann mir auch noch nicht vorstellen, wie das Empfangen funktionieren soll. Wenn es auf Polling hinaus läuft, dann ist es ein gewaltiger Rückschritt.
Wenn du magst, kannst du ja mal nachfragen warum schon wieder die API geändert wird.
Sorry, ich warte aber erstmal ab, bis es stabil und besser dokumentiert ist.
Danke dir Risiko.
Klappt super echt besten dank. Wenn es jetzt noch möglich wäre den Befehl "alarm" zu senden wäre es super denn dann könnte man die Rauchmelder auch über FHEM testen oder z.b. auslösen wenn ein anderer Sensor z.b. CO2 oder bei Einbruch.
Aber bis hierhin schonmal besten dank
Zitat von: Risiko am 30 Juni 2016, 20:10:50
Ok. Erstmal danke für die Infos.
Ich finde es total Schei......, dass die Jungs schon wieder die API ändern.
Kann mir auch noch nicht vorstellen, wie das Empfangen funktionieren soll. Wenn es auf Polling hinaus läuft, dann ist es ein gewaltiger Rückschritt.
Wenn du magst, kannst du ja mal nachfragen warum schon wieder die API geändert wird.
Sorry, ich warte aber erstmal ab, bis es stabil und besser dokumentiert ist.
Bad news. https://forum.pilight.org/Thread-Rewrite-API-not-working?pid=18621#pid18621
Zitat von: Tueftler1983 am 01 Juli 2016, 13:34:54
Danke dir Risiko.
Klappt super echt besten dank. Wenn es jetzt noch möglich wäre den Befehl "alarm" zu senden wäre es super denn dann könnte man die Rauchmelder auch über FHEM testen oder z.b. auslösen wenn ein anderer Sensor z.b. CO2 oder bei Einbruch.
Aber bis hierhin schonmal besten dank
Ok. Wusste nicht, dass man auch senden kann!
Wie sieht denn die Syntax mit pilight-send aus?
Zitat von: alexschomb am 01 Juli 2016, 14:27:11
Bad news. https://forum.pilight.org/Thread-Rewrite-API-not-working?pid=18621#pid18621
Ja leider.
Hab mich mal mit eingeklingt. Habe aber wenig Hoffnung.
Hallo,
Hoffe das hilft bei der Beantwortung deiner frage
https://forum.pilight.org/Thread-Elro-Flamingo-FA20RF-Smoke-detector
Sorry Tueftler1983,
ich möchte nicht selbst den ganzen Thread durcharbeiten.
Du hast doch die Hardware zum Testen. Ich muss eigentlich nur Wissen was ich an pilight senden muss, damit ein Alarm\Testsignal ausgelöst wird.
Zitat von: alexschomb am 01 Juli 2016, 14:27:11
Bad news. https://forum.pilight.org/Thread-Rewrite-API-not-working?pid=18621#pid18621
Good news: https://forum.pilight.org/Thread-Rewrite-API-not-working?pid=18663#pid18663 :D
Habe Grade leider festgestellt das pilight senden mit diesem Protokoll noch nicht unterstützt. Leider
OK. Dann machen wir hier weiter, wenn es in pilight funktioniert.
Hallo zusammen,
ich lese hier schon sehr lange mit und das Forum hat mir schon oft geholfen, mehrere Fehler zu korrigieren.
Nun habe ich aber ein Problem mit fhem & pilight.
Ich habe fhem auf einem rpi3 (192.168.0.211) und pilight 7.0 auf einem rpi2 (192.168.0.212) installiert
Beides funktioniert für sich alleine tadellos.
Nur wenn ich in meinem fhem "define piliow12 pilight_ctrl 192.168.0.212:5000" eingebe,
bekomme ich folgende Meldung "Cannot load module pilight_ctrl".
Muß ich pilight auf beiden rpi´s installieren?
Habe das bisher nicht getan, um meine fhem-installation sauber zu halten.
meine config.json:
{
"devices": {},
"rules": {},
"gui": {},
"settings": {
"port": 5000,
"webserver-http-port": 5001,
"whitelist": "192.168.0.*"
},
"hardware": {
"433gpio": {
"sender": 0,
"receiver": 1
}
},
"registry": {
"pilight": {
"version": {
"current": "7.0"
}
}
}
}
Hallo sat-cracker,
pilight muss nur einmal installiert sein.
Ich vermute eher, dass nicht alle perl Abhängigkeiten (ibjson-perl, libswitch-perl) installiert (rpi3) sind.
Im Log müsste aber auch stehen, warum das Modul nicht geladen werden konnte.
Super, Danke für die Hilfe. Es hat tatsächlich die libswitch-perl gefehlt.
Nun kann ich weiter testen.
Manfred
Hallo,
nachdem ich nun alles soweit am laufen habe, ist mir aufgefallen, das die Geräte, die über pilight-ctrl gefunden werden,
nicht per autocreate angelegt werden.
Sie werden sauber aufgelistet:
rcv_raw
{"message":{"id":65,"temperature":23.5},"origin":"receiver","protocol":"tfa30","uuid":"0000-xx-xx-xx-xxxxxx","repeats":1} 2016-07-08 11:35:59
rcv_raw
{"message":{"systemcode":5,"unitcode":3,"state":"off"},"origin":"receiver","protocol":"elro_800_switch","uuid":"0000-xx-xx-xx-xxxxxx","repeats":1}
2016-07-08 11:38:03
aber nicht angelegt. Das kann autocreate wohl (noch) nicht?
Ist soweit ich weiß extra nicht aktiv da sonst bei rauschen viele Geräte angelegt werden die es ein nicht gibt
kann ich das aber irgendwo einstellen?
Nein. Ist mit Absicht nicht umgesetzt. Das manuelle Anlegen ist einfach durch die Infos im Log mgl. Das automatische Anlegen würde wegen dem Rauschen meiner Meinung nach zu deutlich mehr Problemen führen.
Alles klar, danke für eure Infos. Kein Problem, die paar Geräte von Hand anzulegen.
Hallo Gemeinde,
ich habe vor Tagen Updates von FHEM und meinem System Debian Wheezy (RPi) gemacht. Nun musste ich gestern feststellen, dass meine Automatismen die auf Pilight Schaltungen basieren nicht mehr funktionieren. Grund hierfür war schnell im Log gefunden:
2016.07.15 09:11:51 2: PL_Control(Check): Could not connect to pilight-daemon localhost:5000
2016.07.15 09:12:51 2: PL_Control(Check): Could not connect to pilight-daemon localhost:5000
2016.07.15 09:12:59 2: PL_Control(Check): Could not connect to pilight-daemon localhost:5000
2016.07.15 09:13:12 2: PL_Control(Check): Could not connect to pilight-daemon localhost:5000
2016.07.15 09:13:21 2: PL_Control(Check): Could not connect to pilight-daemon localhost:5000
2016.07.15 09:13:32 2: PL_Control(Check): Could not connect to pilight-daemon localhost:5000
2016.07.15 09:14:33 2: PL_Control(Check): Could not connect to pilight-daemon localhost:5000
der Deamon an sich läuft aber.... Habe die letzten Seiten des Threads gelesen, konnte aber ehrlich gesagt nicht alles nachvollziehen. Gibt es ein Problem mit der API, weil diese verändert wurde ? Haben noch andere diese Probleme ?
Danke und Gruß
Hallo Kermit20,
die API soll so erhalten bleiben. Scheinbar hat sich aber bei einigen Versionen (dachte da aber eher an selbst kompilierte) ein Fehler eingeschlichen.
Welche pilight Version verwendest du?
Hallo Risiko,
Habe mal ne Frage zu pilight. Ist es normal das pilight ne Dauer CPU last von 36-41% verursacht?
Ja, wenn man keinen Hardwarefilter verwendet.
Zitat von: Risiko am 15 Juli 2016, 17:30:04
Hallo Kermit20,
die API soll so erhalten bleiben. Scheinbar hat sich aber bei einigen Versionen (dachte da aber eher an selbst kompilierte) ein Fehler eingeschlichen.
Welche pilight Version verwendest du?
Hi Risiko,
ich war am Wochenende offline.... hier meine Daten:
Version:
pilight-send v7.0
CFG:
{
"devices": {},
"rules": {},
"gui": {},
"settings": {
"port": 5000,
"log-level": 6,
"pid-file": "/var/run/pilight.pid",
"log-file": "/var/log/pilight.log",
"webserver-enable": 1,
"webserver-root": "/usr/local/share/pilight/",
"webserver-http-port": 5001,
"webserver-cache": 1
},
"hardware": {
"433gpio": {
"sender": 0,
"receiver": 1
}
},
"registry": {
"pilight": {
"firmware": {
"version": 22493,
"lpf": 464980,
"hpf": 327290
},
"version": {
"current": "7.0"
}
}
}
}
LIST vom CTRL
Internals:
API 6.0
DEF localhost:5000
DeviceName localhost:5000
NAME PL_Control
NR 155
NTFY_ORDER 50-PL_Control
PARTIAL
RETRY_INTERVAL 60
STATE disconnected
TYPE pilight_ctrl
Readings:
2016-07-17 22:21:59 rcv_raw empty
2016-07-18 12:41:32 state disconnected
Helper:
CHECK 1
CON disconnected
NEXT_TRY 1468838551.50749
sendQueue:
whiteList:
quigg_gt7000:1632
Attributes:
DbLogExclude .*Was mir komisch vorkommt ist die Passage mit dem high und Low Filter... der kommt mir unbekannt vor.
ich habe weitergesucht und eben einen Versuch unternommen... der nun die Lösung gebracht hat:
Internals:
API 6.0
DEF 192.168.xxx.yyy:5000
DeviceName 192.168.xxx.yyy:5000
FD 43
NAME PL_Control
NR 155
NTFY_ORDER 50-PL_Control
PARTIAL
RETRY_INTERVAL 60
STATE connected
TYPE pilight_ctrl
Readings:
2016-07-17 22:21:59 rcv_raw empty
2016-07-18 15:21:42 state connected
Helper:
CON connected
LAST_RCV_RAW {"status":"success"}
sendQueue:
whiteList:
Attributes:
DbLogExclude .*
Ich habe in der Definition von localhost auf die IP des RPi umgestellt (obwohl es das selbe Gerät ist...) nun geht es. erklären kann ich es mir nicht.... werde bei Gelegenheit mal Suchen -> oder gab es in einem FHEM Update eine Änderung ?
Kann mich mir leider auch nicht erklären.
Aber es ist ja super, dass es jetzt wieder geht.
Hallo zusammen,
ich habe am Raspi einen Filter hängen und das Pilight-Modul installiert.
Das funktioniert allerdings so gut, dass ich auch den Müll von meinen Nachbarn mitlesen kann. ;D
Jetzt kann man ja anscheinend ganze Protokolle ignorieren. Allerdings verstehe ich den Synthax nicht so richtig.
Wie muss denn "attr ignoreProtocol ..." bei folgendem unerwünschtem Empfang aussehen?
2016.08.03 23:18:59 3: it_ctrl: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2016.08.03 23:18:59 3: it_ctrl: Unknown code PITEMP,alecto_ws1700,1399,temperature:20.4,humidity:23,battery:1, help me!
Danke
Hallo presskopf,
steht doch schon alles hier im Thread ;)
ignoreProtocol alecto_wsd17:4095,alecto_ws1700:1399 --> genau diese beiden
ignoreProtocol alecto_wsd17:*,alecto_ws1700:* --> alles vom Protokoll alecto_wsd17 und alecto_ws1700
Ich empfehle einfach ignoreProtocol * --> alles ignorieren bis auf die eigene Protokolle durch die defines in fhem
Risiko
Au Mann ja, ich werde alt. Sry, habe den Wald vor Bäumen nicht gesehen... 8)
Danke!
Hallo,
vielen Dank für die feinen Module! Es ist mir bereits gelungen mehrere Brennenstuhl-Funksteckdosen einzubinden und zu schalten. Allerdings hakt es bei einer Logilink-Funksteckdose, diese lässt sich einbinden, aber nicht nicht schalten.
pilight-daemon: ERROR: logilink_switch: insufficient number of arguments
Ist das Protokoll einfach noch nicht implementiert oder mache ich etwas falsch?
So sieht das Ganze in Fhem aus:
DEF logilink_switch 65813 3
ID 65813
IODev myPilight
NAME LogiLight
NR 23
PROTOCOL logilink_switch
STATE defined
TYPE pilight_switch
Vielen Dank im Voraus!
Hallo joergbutt,
sorry für die späte Meldung. Bin aber gerade anderweitig sehr beschäftigt.
Das Protokoll logilink_switch wird aktuell nicht unterstützt. Kannst du mir sagen, mit welchen ID's es funktioniert. Was meldet pilight-receive?
Dann kann ich es mit aufnehmen.
Risiko
Hallo an alle,
erst einmal ein herzliches Dankeschön für dieses Modul. Leider habe ich aktuell damit Probleme, ein Device zu definieren. Ich versuche via dem Modul pilight_ctrl und pilight eine Quigg Steckdose in FHEM zu integrieren. Leider schlägt dies bereits bei der Definition fehl.
Fehlermeldung: "Cannot load module pilight" bzw "Cannot load module pilight_ctrl". Beide Dateien sind im Ordner /opt/fhem/FHEM/ vorhanden. Ich nutze einen Raspberry 3 mit Raspbian/Debian Jessie, die aktuellste FHEM Version (5.7 wenn ich richtig liege) und die aktuellste pilight Version (7.0). Natürlich läuft pilight auch im Hintergrund. Ich habe auch schon das modul 98_pilight.pm mehrfach neu heruntergeladen und mit dem bereits vorhandenen ersetzt. Trotzdem kommt nur diese Fehlermeldung. Liegt es an der FHEM Version, an der Pilight Version oder daran, dass ich aktuell nicht den 433MHz Sender angeschlossen habe, sondern "nur" einen Busware-Stick? Oder bin ich auf dem Holzweg?
Falls jemand hilfreiche Tips/Ideen hat, wäre ich unendlich dankbar. Ich denke eine andere Möglichkeit eine Quigg GT7000 einzubinden in FHEM außer via pilight gibt es nicht?
Grüße
Zitat von: Impulse am 13 September 2016, 15:25:28
Hallo an alle,
erst einmal ein herzliches Dankeschön für dieses Modul. Leider habe ich aktuell damit Probleme, ein Device zu definieren. Ich versuche via dem Modul pilight_ctrl und pilight eine Quigg Steckdose in FHEM zu integrieren. Leider schlägt dies bereits bei der Definition fehl.
Fehlermeldung: "Cannot load module pilight" bzw "Cannot load module pilight_ctrl". Beide Dateien sind im Ordner /opt/fhem/FHEM/ vorhanden. Ich nutze einen Raspberry 3 mit Raspbian/Debian Jessie, die aktuellste FHEM Version (5.7 wenn ich richtig liege) und die aktuellste pilight Version (7.0). Natürlich läuft pilight auch im Hintergrund. Ich habe auch schon das modul 98_pilight.pm mehrfach neu heruntergeladen und mit dem bereits vorhandenen ersetzt. Trotzdem kommt nur diese Fehlermeldung. Liegt es an der FHEM Version, an der Pilight Version oder daran, dass ich aktuell nicht den 433MHz Sender angeschlossen habe, sondern "nur" einen Busware-Stick? Oder bin ich auf dem Holzweg?
Falls jemand hilfreiche Tips/Ideen hat, wäre ich unendlich dankbar. Ich denke eine andere Möglichkeit eine Quigg GT7000 einzubinden in FHEM außer via pilight gibt es nicht?
Grüße
Setz dein Verbose ggf hoch,und schau mal in dein Logfile. Ich meine da findest du einen Hinweis auf die Pakete die dir fehlen..Ich glaube einige Seiten vorher hatte auch schon einmal jemand das Problem. Ich schau mal eben ob ich das finde!
Edit
Zitat von: sat-cracker am 04 Juli 2016, 13:33:28
Hallo zusammen,
ich lese hier schon sehr lange mit und das Forum hat mir schon oft geholfen, mehrere Fehler zu korrigieren.
Nun habe ich aber ein Problem mit fhem & pilight.
Ich habe fhem auf einem rpi3 (192.168.0.211) und pilight 7.0 auf einem rpi2 (192.168.0.212) installiert
Beides funktioniert für sich alleine tadellos.
Nur wenn ich in meinem fhem "define piliow12 pilight_ctrl 192.168.0.212:5000" eingebe,
bekomme ich folgende Meldung "Cannot load module pilight_ctrl".
Muß ich pilight auf beiden rpi´s installieren?
Habe das bisher nicht getan, um meine fhem-installation sauber zu halten.
meine config.json:
{
"devices": {},
"rules": {},
"gui": {},
"settings": {
"port": 5000,
"webserver-http-port": 5001,
"whitelist": "192.168.0.*"
},
"hardware": {
"433gpio": {
"sender": 0,
"receiver": 1
}
},
"registry": {
"pilight": {
"version": {
"current": "7.0"
}
}
}
}
Zitat von: Risiko am 04 Juli 2016, 18:35:45
Hallo sat-cracker,
pilight muss nur einmal installiert sein.
Ich vermute eher, dass nicht alle perl Abhängigkeiten (ibjson-perl, libswitch-perl) installiert (rpi3) sind.
Im Log müsste aber auch stehen, warum das Modul nicht geladen werden konnte.
Hallo Esjaycc,
danke für deinen Tipp. In der Tat habe ich noch nicht im Log nachgeschaut. libjson-perl fehlt, bin gerade dabei alle Abhängigkeiten zu installieren. Danach sollte ich das Device zumindest schonmal erstellen können. Ansonsten melde ich mich :P Ob es dann mitm schalten klappt, das ist eine andere Frage.
Grüße
Hallo,
ich benötige ein wenig Hilfe mit einem Kaku_contact.
In Pilight funzt er soweit, bekomme ihn jedoch nicht in Fhem ausgelesen:
define pilight pilight_ctrl IP:5000
attr pilight ContactAsSwitch 43296768
define Wandschalter_wz1 pilight_switch kaku_switch 43296768 1
Pilight conf.jason:
"contact1_o": {
"protocol": [ "kaku_contact" ]
"id": [{
"id": 43296768,
"unit": 1
}],
"state": "opened"
},
Hab es mit kaku_contact als Protokol versucht... mit brands und ohne... der Status des pilight_switch in FHEM bleibt unverändert und steht auf "defined". Oder muss ich in pilight noch einen Schalter definieren und den dann abfangen?
Hallo Risiko,
ich muss auch hier mal stören 8)
Bei meinen beiden FHEM Installationen bekomme ich beim starten folgende Fehlermeldungen:
2016.09.19 17:40:37 1: PERL WARNING: Subroutine BC_searchTelnet redefined at ./FHEM/Blocking.pm line 36, <$fh> line 159.
2016.09.19 17:40:37 1: PERL WARNING: Subroutine BlockingCall redefined at ./FHEM/Blocking.pm line 71, <$fh> line 159.
2016.09.19 17:40:37 1: PERL WARNING: Subroutine BlockingStart redefined at ./FHEM/Blocking.pm line 83, <$fh> line 159.
2016.09.19 17:40:37 1: PERL WARNING: Subroutine BlockingInformParent redefined at ./FHEM/Blocking.pm line 155, <$fh> line 159.
2016.09.19 17:40:37 1: PERL WARNING: Subroutine BlockingKill redefined at ./FHEM/Blocking.pm line 205, <$fh> line 159.
2016.09.19 17:40:37 1: PERL WARNING: Subroutine BlockingExit redefined at ./FHEM/Blocking.pm line 234, <$fh> line 159.
Nachdem dies scheinbar nicht bei allen so ist habe ich begonnen Stück für Stück die Defines aus meiner Konfiguration zu entfernen und jedes mal neu zu starten.
Kurz gesagt, ich konnte 10_pilight_ctrl.pm als Übeltäter ausmachen.
Das auskommentieren der Zeile 89:
require "$attr{global}{modpath}/FHEM/Blocking.pm";
lässt die Warnungen verschwinden.
Meiner Meinung nach ist sie auch nicht notwendig, da Blocking.pm standardmäßig geladen wird.
Grüße
Klaus
Wie kommst du denn zu der Aussage, dass Blocking.pm standardmäßig geladen wird?
Ich hab was geändert. Bitte mal testen.
Danke.
Zitat von: Risiko am 20 September 2016, 19:55:20
Wie kommst du denn zu der Aussage, dass Blocking.pm standardmäßig geladen wird?
ist eine Vermutung (hätte ich dazu schreiben sollen), im Beispiel in der blocking.pm ist nix von require geschrieben
Zitat von: Risiko am 20 September 2016, 19:55:20
Ich hab was geändert. Bitte mal testen.
Mache ich, danke!
Bei dir treten diese Fehler nicht auf?
Änderung scheint zu funktionieren. Warnungen sind verschwunden.
hi,
ich habe das problem, dass meine elroFB das signal teilweise mehrfach sendet... somit wird dann auch mehrfach geschaltet. kann ich irgendwie konfigurieren dass empfangene signale nur einmal verarbeitet werden? so dass z.b. erst nach 2 sekunden wieder das selbe signal kommen darf?
gruß erotikbaer
Halle erotikbaer,
nein aktuell gibt es da keine Möglichkeit.
Leide hab ich das Problem auch noch nicht verstanden. Selbst wenn die FB das Signal mehrfach sendet, was soll denn da mehrfach geschalten werden? Es ist doch immer der gleiche Zustand.
Risiko
schade :( ich habe es bei mir so konfiguriert, dass wenn ich per fernbedienung meine Lampe einschalte per Text2Speech etwas ausgegeben wird. und jetzt wirds teilweise mehrfach ausgegeben wenn man die fernbedienung etwas länger betätigt.
Kannst du nicht einfach die Text2Speech Ausgabe für eine Zeit blockieren.
hm keine ahnung wie das gehen könnte und streng genommen wäre das auch eher störend, denn wenn ich zum beispiel zwei sachen hintereinander schalten wollen würde, würde dies dann nicht funktionieren. verstehst du wie ich das meine?
Hi, kann man nicht mit der FB einen Dummy schalten und der wertet einen Zustand aus bevor mittels doif der eigentliche Schalter geschaltet wird und der Zustand aktualisiert wird? Also im Grunde die Logik mit Löschen von Befehlen bis zum Zeitversatz im Dummy abbilden ;-)
Gesendet von iPhone mit Tapatalk
Hi,
ich habe einfach meinen 433 Mhz Empfänger, der am GPIO des Raspberry hängt, nach meiner "Anlernphase" des Intertechno Systems auf einen anderen GPIO Port konfiguriert in der config.json von PiLight. Somit kommt kein Funktraffic bei PiLight mehr an und der Filter (und somit auch die CPU) hat nichts mehr zu tun.
Evtl. verstehe ich etwas falsch, aber für mich ist das so kein Nachteil. Weil das Schalten über den 433 Mhz Sender funktioniert ja nach wie vor einwand frei. Oder verpasse ich hier etwas von der Idee? Evtl. das keine Events mehr von der Fernbedienung eingefangen werden?
Ich frage, da ich noch keine externe Antenne an den Empfänger gelötet habe, und somit die Funktion des Empfängers noch nicht großartig getestet habe (z. B. im Zusammenspiel mit der Fernbedienung).
Danke
Zitat von: Tueftler1983 am 17 Juli 2016, 22:41:46
Hallo Risiko,
Habe mal ne Frage zu pilight. Ist es normal das pilight ne Dauer CPU last von 36-41% verursacht?
Hi BerHa,
das wurde hier schon öfter diskutiert. Ja ohne Filter ist das so! Einfach mal im Thread suchen.
Ich versuche meine 433 MHz Fernbedienung mit geändertem Systemcode an den Pi anzulernen.
Das Dumme ist, dass die Dosen per Protokoll elro_800_switch gesteuert werden, pilight-receive die Befehle der Fernbedienung aber für an und aus als das hier erkennt:
{
"message": {
"unitcode": 700075,
"state": "opened"
},
"origin": "receiver",
"protocol": "ev1527",
"uuid": "0000-b8-27-eb-77622d",
"repeats": 1
}
{
"message": {
"unitcode": 700075,
"state": "closed"
},
"origin": "receiver",
"protocol": "ev1527",
"uuid": "0000-b8-27-eb-77622d",
"repeats": 1
}
Ich weiß nun nicht wie ich das einbinden kann.
Ich habe zwar über ContactAsSwitch gelesen, weiß aber nicht wie ich das in diesem Fall definieren soll.
Wenn ich das hier bei der pilight_ctrl mache
attr ContactAsSwitch 700075
und das hier als device:
define FernbedienungWZA1 pilight_switch ev1527 700075
define FernbedienungWZA1_on notify FernbedienungWZA1:on set KommodeLampe on
kriege ich beim Speichern der config Syntax-Fehlermeldungen.
Hi Pati_Alpha,
ContactAsSwitch funktioniert aktuell nur für Protokolle mit 'contact' im Namen. Also leider nicht für 'ev1527'.
Als ich das entwickelt habe, gab es nur Protokolle mit 'contact' z.B. kaku_contact.
Wenn ich es schaffe, dann schau ich am Wochenende mal, ob ich da was machen kann.
Risiko.
Vielen vielen Dank! :)
Sowieso herzlichen Dank für das tolle Modul!! :)
Hier mal eine Version zum Testen.
Das habe ich noch nicht geschafft.
Ich habe noch eine andere Frage:
Könnte man auch bei "pilight_raw" das Attribut "sendCount" nutzbar machen?
Ich habe im Gartenhaus zwei 433er Empfänger die ich bei Regen oft schlecht erreiche, wenn ich jedoch mehrfach versuche geht es. Leider musste ich die beiden über RAW-Codes steuern, da die Signale ansonsten nicht mit pilight interpretierbar waren.
Wenn ich nun allerdings einfach den RAW-Code mehrfach hintereinander kopiere reagieren die Teile garnicht mehr. :(
---------------------
Zu pilight_ctrl:
Mir ist grade mein neuer RXB6 Empfänger abgeraucht. :/ Die GPIOs funktionieren noch, Widerstände sind alle noch da und das billige Empfängerding was beim FS1000a-Sender dabei war, was aber wirklich unnutzbar wenig Reichweite hat funktioniert an den Anschlüssen auch noch.
Komme daher erst wenn ich das Teil umgetauscht habe zum richtigen Testen des neuen pilight_ctrl. :(
Wirklich komisch. Ich hatte den RXB6 an 5V, hatte eine Antenne dran und den DATA-Anschluss über einen Spannungsteiler mit 2x 10kOhm-Widerständen auf GPIO und GND, sodass am GPIO ca. 2,5V ankommen. Frage mich wie das Teil dabei kaputt gehen konnte?! Werd es auf jeden Fall reklamieren.
Habe sendCount in pilight_raw eingebaut.
Viel Spaß beim Testen.
Super!! Besten Dank! :)
Zum ContactAsSwitch melde ich mich auch sobald ich meinen Empfänger ersetzt habe.
Ich hab jetzt mal (mit neuem, funktionierendem Empfänger) folgendes mit deinem neuen Test-Modul versucht:
define pilight pilight_ctrl localhost:5000 7.0
attr pilight verbose 5
attr pilight ContactAsSwitch 700073
und
define FernbedienungWZA1 pilight_switch ev1527 700073
define FernbedienungWZA1_on notify FernbedienungWZA1:on set KommodeLampe on
Aber ich bekomme direkt nur die Antwort:
ERROR: wrong syntax: define pilight_switch [systemcode]
Er erkennt also ev1527 garnicht an bei pilight_switch. Auch wenn ich "ev1527" weglasse nicht, gleiche Fehlermeldung.
Muss ich das vorher noch irgendwo in einer pilight-config-Datei deklarieren?
Sorry, hatte da nen Denkfehler.
Für das Protokoll ev1527 gibt es ja überhaupt kein Switch. Somit geht das mit ContactAsSwitch auch nicht.
Muss da nochmal darüber nachdenken. Es wird aber sehr wahrscheinlich auf ein neues Modul "pilight_contact" hinauslaufen.
Werde ich aber dieses WE nicht schaffen.
Risiko.
Mach dir keinen Stress!
Das hört sich aber super an, da ich sowieso gerne bald noch 2-3 Kontaktsensoren in FHEM einbinden möchte und hoffe, das auch über dein plugin machen zu können ohne einen CUL zu kaufen.
So neues Modul 30_pilight_contact soeben eingecheckt.
ContactAsSwitch darf in pilight_ctrl nicht gesetzt sein!
Mit ev1527 konnte ich es natürlich nicht testen
Hallo,
ich habe ein Problem mit dem Modul - und zwar kann ich immer nur *einmal* schalten. Danach muss ich neu verbinden, um erneut schalten zu können. Empfangen geht allerdings immer. Auch, wenn ich nicht mehr schalten kann.
Der pilight-daemon (pilight-daemon version v7.0) läuft auf einem Raspberry Pi, fhem läuft auf Freeebsd.
Mein pilight_ctrl device hat ignoreProtocol * gesetzt, wenn ich das raus nehme ändert es aber auch nichts.
Die pilight_switch devices scheinen korrekt konfiguriert zu sein (empfangen und einmal schalten funktioniert ja auch), z. B. "elro_800_switch 5 1", "... 5 2" etc.
Jemand eine Idee woran es liegen könnte?
Ich habe pilight_contact jetzt getestet:
define Fernbedienung pilight_contact ev1527 700415
Per "pilight-receive" habe ich vorher folgendes von der FB empfangen:
{
"message": {
"unitcode": 700415,
"state": "closed"
},
"origin": "receiver",
"protocol": "ev1527",
"uuid": "0000-b8-27-eb-77622d",
"repeats": 30
}
(bzw. das gleiche in "open" wenn ich die Aus-Taste drücke)
Das Problem ist: das device steht nur auf "defined" und es passiert nichts.
Das log sagt dazu:
2016.11.14 23:48:31 5: Starting notify loop for pilight, first event rcv_raw: {"message":{"unitcode":700415,"state":"closed"},"origin":"receiver","protocol":"ev1527","uuid":"0000-b8-27-eb-77622d","repeats":1}
2016.11.14 23:48:31 3: pilight(Parse): ERROR no or unknown id {"message":{"unitcode":700415,"state":"closed"},"origin":"receiver","protocol":"ev1527","uuid":"0000-b8-27-eb-77622d","repeats":1}
Sagt dir das irgendwas? :(
Hi. Habe das Problem erkannt.
Das Protokoll ist etwas eigenwillig. Hat unitcode als Haupt-ID, wo alle anderen Protokolle ID haben.
Ich habe eine neue Version eingecheckt
Jetzt läuft es!!!! :D Top!!!
Riesen Dank an dich!!!
Ich wette bald wird man sich dank dieser Module fragen, wozu man überhaupt noch ein CuL433 braucht! ;)
Nachtrag: beim Protokoll "elro_800_contact" passiert das gleiche wie vorher beim ev1527: es bleibt auf defined und sonst passiert nichts. Ist vielleicht der gleiche Bug an anderer Stelle?
Noch ein Nachtrag (sorry fürs Spammen):
Es ist wie verhext, jetzt schaltet mein Gartenlicht auch nur noch auf "defined".
Code ist folgender:
define GartenVorneLampe pilight_switch kaku_switch 19162090 0
attr GartenVorneLampe IODev pilight
attr GartenVorneLampe alias GartenVorne
attr GartenVorneLampe group Licht
attr GartenVorneLampe room Homekit,Garten
attr GartenVorneLampe sortby 1
Ansonsten interagiert absolut nichts mit dem device (DOIFs oder sonstiges). Wenn ich im Webinterface auf "on" klicke geht das Licht zwar an, aber der Status bleibt "defined". Bei anderen "pilight_switch" Geräten, die andere Protokolle nutzen geht es aber und hier ging es vorher auch...! :/
Zitat von: Pati_Alpha am 16 November 2016, 17:20:16
Ansonsten interagiert absolut nichts mit dem device (DOIFs oder sonstiges). Wenn ich im Webinterface auf "on" klicke geht das Licht zwar an, aber der Status bleibt "defined". Bei anderen "pilight_switch" Geräten, die andere Protokolle nutzen geht es aber und hier ging es vorher auch...! :/
Verbose wieder auf 5 stellen (ctrl und switch) und mal schauen was da ankommt.
Vielleicht ist da doch ein Fehler rein gekommen. Ich selbst habe keine Probleme festgestellt!
2016.11.17 22:45:09 5: Cmd: >set GartenVorneLampe off<
2016.11.17 22:45:09 5: GartenVorneLampe(Set): off 1 of 1
2016.11.17 22:45:09 4: pilight(Write): RCV (pilight_switch) -> GartenVorneLampe,off
2016.11.17 22:45:09 4: pilight(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":19162090,"unit":0,"off":1}}
2016.11.17 22:45:09 5: pilight(SendNonBlocking): queue size 1
2016.11.17 22:45:09 4: BlockingCall (pilight_ctrl_Send): created child (6595), uses telnetForBlockingFn_1479413966 to connect back
2016.11.17 22:45:09 4: name: /fhem?cmd.GartenVorneLampe=set%20GartenVorneLampe%20off&room=Garten&XHR=1&fw_id=813 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.17 22:45:09 5: pilight(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":19162090,"unit":0,"off":1}}
2016.11.17 22:45:09 4: pilight(Send): RCV -> {"status":"success"}
2016.11.17 22:45:09 4: Connection accepted from telnetForBlockingFn_1479413966_127.0.0.1_49116
2016.11.17 22:45:09 5: Cmd: >{BlockingStart('12378')}<
2016.11.17 22:45:09 5: Cmd: >{pilight_ctrl_SendDone('pilight|1')}<
2016.11.17 22:45:09 4: pilight(SendDone): message successfully send
2016.11.17 22:45:10 5: pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":19162090,"unit":0,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.17 22:45:10 5: Triggering pilight (1 changes)
2016.11.17 22:45:10 5: Starting notify loop for pilight, first event rcv_raw: {"origin":"sender","protocol":"arctech_switch","message":{"id":19162090,"unit":0,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.17 22:45:10 4: pilight(Dispatch): PISWITCH,arctech_switch,19162090,0,off
2016.11.17 22:45:10 5: pilight dispatch PISWITCH,arctech_switch,19162090,0,off
2016.11.17 22:45:10 4: pilight_switch_Parse: RCV -> PISWITCH,arctech_switch,19162090,0,off
2016.11.17 22:45:10 5: Triggering pilight (1 changes)
2016.11.17 22:45:10 5: Starting notify loop for pilight, first event UNKNOWNCODE PISWITCH,arctech_switch,19162090,0,off
2016.11.17 22:45:10 3: pilight: Unknown code PISWITCH,arctech_switch,19162090,0,off, help me!
Habe nochmal etwas rumprobiert, bei "kaku_switch" und "arctech_switch" passiert das, bei zB elro_800_switch nicht. Kann es sein, dass die Protokolle für die du das pilight_contact erstellt (oder erweitert) hast jetzt diesen Schuss weg haben?
Pilight scheint ja generell kein Problem zu haben, denn das Schalten funktioniert ja, nur das FHEM-Modul ändert den state bei diesen Protokollen nicht.
Ich hoffe das bringt dich weiter?
EDIT:
Ich habe nochmal etwas anderes ausprobiert:
Das hier:
define TestDing pilight_switch kaku_switch 12 1
ergibt das hier:
2016.11.17 23:23:01 5: Cmd: >set TestDing off<
2016.11.17 23:23:01 5: TestDing(Set): off 1 of 1
2016.11.17 23:23:01 4: pilight(Write): RCV (pilight_switch) -> TestDing,off
2016.11.17 23:23:01 4: pilight(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":12,"unit":1,"off":1}}
2016.11.17 23:23:01 5: pilight(SendNonBlocking): queue size 1
2016.11.17 23:23:01 4: BlockingCall (pilight_ctrl_Send): created child (21086), uses telnetForBlockingFn_1479421337 to connect back
2016.11.17 23:23:01 4: name: /fhem?cmd.TestDing=set%20TestDing%20off&room=all&XHR=1&fw_id=389 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.17 23:23:01 5: pilight(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":12,"unit":1,"off":1}}
2016.11.17 23:23:01 4: pilight(Send): RCV -> {"status":"success"}
2016.11.17 23:23:01 4: Connection accepted from telnetForBlockingFn_1479421337_127.0.0.1_44802
2016.11.17 23:23:01 5: Cmd: >{BlockingStart('135')}<
2016.11.17 23:23:01 5: Cmd: >{pilight_ctrl_SendDone('pilight|1')}<
2016.11.17 23:23:01 4: pilight(SendDone): message successfully send
2016.11.17 23:23:02 5: pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":12,"unit":1,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.17 23:23:02 5: Triggering pilight (1 changes)
2016.11.17 23:23:02 5: Starting notify loop for pilight, first event rcv_raw: {"origin":"sender","protocol":"arctech_switch","message":{"id":12,"unit":1,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.17 23:23:02 4: pilight(Dispatch): PISWITCH,arctech_switch,12,1,off
2016.11.17 23:23:02 5: pilight dispatch PISWITCH,arctech_switch,12,1,off
2016.11.17 23:23:02 4: pilight_switch_Parse: RCV -> PISWITCH,arctech_switch,12,1,off
2016.11.17 23:23:02 5: Triggering pilight (1 changes)
2016.11.17 23:23:02 5: Starting notify loop for pilight, first event UNKNOWNCODE PISWITCH,arctech_switch,12,1,off
2016.11.17 23:23:02 3: pilight: Unknown code PISWITCH,arctech_switch,12,1,off, help me!
und es schaltet den Status nicht. Das Selbe bei "arctech_switch".
Wohingegen das hier:
define TestDing2 pilight_switch elro_800_switch 12 1
das hier ergibt:
2016.11.17 23:26:35 5: Cmd: >set TestDing2 off<
2016.11.17 23:26:35 5: TestDing2(Set): off 1 of 1
2016.11.17 23:26:35 4: pilight(Write): RCV (pilight_switch) -> TestDing2,off
2016.11.17 23:26:35 4: pilight(Write): {"action":"send","code":{"protocol":["elro_800_switch"],"systemcode":12,"unitcode":1,"off":1}}
2016.11.17 23:26:35 5: pilight(SendNonBlocking): queue size 1
2016.11.17 23:26:35 4: BlockingCall (pilight_ctrl_Send): created child (22493), uses telnetForBlockingFn_1479421571 to connect back
2016.11.17 23:26:35 4: name: /fhem?cmd.TestDing2=set%20TestDing2%20off&room=all&XHR=1&fw_id=387 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.17 23:26:35 5: pilight(Send): {"action":"send","code":{"protocol":["elro_800_switch"],"systemcode":12,"unitcode":1,"off":1}}
2016.11.17 23:26:35 4: pilight(Send): RCV -> {"status":"success"}
2016.11.17 23:26:35 4: Connection accepted from telnetForBlockingFn_1479421571_127.0.0.1_37692
2016.11.17 23:26:35 5: Cmd: >{BlockingStart('7')}<
2016.11.17 23:26:35 5: Cmd: >{pilight_ctrl_SendDone('pilight|1')}<
2016.11.17 23:26:35 4: pilight(SendDone): message successfully send
2016.11.17 23:26:35 5: pilight(Parse): RCV -> {"origin":"sender","protocol":"elro_800_switch","message":{"systemcode":12,"unitcode":1,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.17 23:26:35 5: Triggering pilight (1 changes)
2016.11.17 23:26:35 5: Starting notify loop for pilight, first event rcv_raw: {"origin":"sender","protocol":"elro_800_switch","message":{"systemcode":12,"unitcode":1,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.17 23:26:35 4: pilight(Dispatch): PISWITCH,elro_800_switch,12,1,off,12
2016.11.17 23:26:35 5: pilight dispatch PISWITCH,elro_800_switch,12,1,off,12
2016.11.17 23:26:35 4: pilight_switch_Parse: RCV -> PISWITCH,elro_800_switch,12,1,off,12
2016.11.17 23:26:35 5: Triggering TestDing2 (1 changes)
2016.11.17 23:26:35 5: Starting notify loop for TestDing2, first event off
und der Status schaltet.
Was hat es mit dem "UNKNOWNCODE PISWITCH" auf sich?
In der Kommandozeile mit "pilight-send" ist er mit beidem zufrieden, aber wie gesagt: die Gartenlampe schaltet ja auch, trotz "UNKNOWNCODE"...
Hallo Pati_Alpha,
das ist ein typisches Problem von pilight. Für ein und das selbe Protokoll gibt es unterschiedliche Namen (brands) Für kakau_switch z.B. intertechno_switch, dio_switch,coco_switch, arctech_switch, etc.
Senden tust du entsprechenden deiner switch definition mit dem kaku_switch Protokoll
pilight(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":19162090,"unit":0,"off":1}}
Antworten tut pilight aber mit arctech_switch
pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":19162090,"unit":0,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
Für das arctech_switch Protokoll wird aber nun keine Schalter-Definition\Modul gefunden -->Unknown code....
Es gibt dafür zwei Lösungen:
1. Du definierst den Schalter mit dem Protokoll arctech_switch
2. Du nutzt das Attribut 'brands' in pilight_ctrl archtech:kaku --> Jetzt wird archtech zu kaku umbenannt
Hast du evtl. die pilight Version gewechselt? Kann eigentlich sonst nie funktioniert haben. Es hat also nichts mit den Änderungen bezüglich der Kontakte zu tun.
Risiko
Hey,
das kann eigentlich nicht sein. Ich habe nur deine Module geupdated. Pilight selbst habe ich seit Beginn meines FHEM Projekts vor 6 Wochen nicht wieder angefasst.
Davon ab bin mir SICHER (!!), dass es vorher funktioniert hat. :/
Außerdem habe ich ja folgendes getestet:
define TestDing pilight_switch kaku_switch 12 1
ergibt
2016.11.18 23:16:16 5: Cmd: >set TestDing on<
2016.11.18 23:16:16 5: TestDing(Set): on 1 of 1
2016.11.18 23:16:16 4: pilight(Write): RCV (pilight_switch) -> TestDing,on
2016.11.18 23:16:16 4: pilight(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":12,"unit":1,"on":1}}
2016.11.18 23:16:16 5: pilight(SendNonBlocking): queue size 1
2016.11.18 23:16:16 4: BlockingCall (pilight_ctrl_Send): created child (569), uses telnetForBlockingFn_1479507231 to connect back
2016.11.18 23:16:16 4: name: /fhem?cmd.TestDing=set%20TestDing%20on&XHR=1&fw_id=404 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.18 23:16:16 5: pilight(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":12,"unit":1,"on":1}}
2016.11.18 23:16:16 4: pilight(Send): RCV -> {"status":"success"}
2016.11.18 23:16:16 4: Connection accepted from telnetForBlockingFn_1479507231_127.0.0.1_60874
2016.11.18 23:16:16 5: Cmd: >{BlockingStart('8424')}<
2016.11.18 23:16:16 5: Cmd: >{pilight_ctrl_SendDone('pilight|1')}<
2016.11.18 23:16:16 4: pilight(SendDone): message successfully send
2016.11.18 23:16:17 5: pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":12,"unit":1,"state":"on"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.18 23:16:17 5: Triggering pilight (1 changes)
2016.11.18 23:16:17 5: Starting notify loop for pilight, first event rcv_raw: {"origin":"sender","protocol":"arctech_switch","message":{"id":12,"unit":1,"state":"on"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.18 23:16:17 4: pilight(Dispatch): PISWITCH,arctech_switch,12,1,on
2016.11.18 23:16:17 5: pilight dispatch PISWITCH,arctech_switch,12,1,on
2016.11.18 23:16:17 4: pilight_switch_Parse: RCV -> PISWITCH,arctech_switch,12,1,on
und
define TestDing pilight_switch kaku_switch 12 1
ergibt
2016.11.18 23:17:59 5: Cmd: >set TestDing on<
2016.11.18 23:17:59 5: TestDing(Set): on 1 of 1
2016.11.18 23:17:59 4: pilight(Write): RCV (pilight_switch) -> TestDing,on
2016.11.18 23:17:59 4: pilight(Write): {"action":"send","code":{"protocol":["arctech_switch"],"id":12,"unit":1,"on":1}}
2016.11.18 23:17:59 5: pilight(SendNonBlocking): queue size 1
2016.11.18 23:17:59 4: BlockingCall (pilight_ctrl_Send): created child (1306), uses telnetForBlockingFn_1479507454 to connect back
2016.11.18 23:17:59 4: name: /fhem?cmd.TestDing=set%20TestDing%20on&room=all&XHR=1&fw_id=386 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.18 23:17:59 5: pilight(Send): {"action":"send","code":{"protocol":["arctech_switch"],"id":12,"unit":1,"on":1}}
2016.11.18 23:17:59 4: pilight(Send): RCV -> {"status":"failed"}
2016.11.18 23:17:59 4: Connection accepted from telnetForBlockingFn_1479507454_127.0.0.1_41572
2016.11.18 23:17:59 5: Cmd: >{BlockingStart('8435')}<
2016.11.18 23:17:59 5: Cmd: >{pilight_ctrl_SendDone('pilight|1')}<
2016.11.18 23:17:59 4: pilight(SendDone): message successfully send
Du hast natürlich recht, das obere ist länger, weil er da separat etwas mit dem Namen "arctech" empfängt und unten nicht (da es ja schon von vornherein arctech ist), aber in beiden Fällen schaltet der status des device nicht!
Wohingegen es mit "elro_800_switch" zB funktioniert.
Funktioniert das "TestDing" denn bei dir mit beiden Protokollen?
Hallo,
ich wollte kurz nachfragen, ob man den zuvor besprochenen Problem schon auf die Schliche gekommen ist, denn ich habe das selbe Problem.
Habe vorgestern eine JeeLink mit LaCrose installiert und in dem Atemzug ein Update von FHEM gemacht. Seit dem kann ich keine Kaku Switch Funksteckdosen mehr schalten, weder mit FHEM oder Pilight direkt.
Wenn aber FHEM nicht läuft, sondern nur Pilight, dann kann ich die Kaku Switch Funksteckdosen schalten. Habe noch drei weitere Funksteckdosen die mit dem Elro 800 Protokoll angesteuert werden, bei diesen gibt es wiederum keine Probleme.
Darüber hinaus lasse ich noch einen DHT22 über Pilight laufen, der spinnt jetzt auch rum, kann aber auch andere Gründe haben.
Würde mich sehr über Antworten freuen
Zitat von: Pati_Alpha am 18 November 2016, 23:20:06
Funktioniert das "TestDing" denn bei dir mit beiden Protokollen?
Es funktioniert nur
define TestDing pilight_switch kaku_switch 12 1wenn man wie bereits erwähnt das Attribut brands setzt. "attr <name> brands arctech:kaku"
Mit "arctech_switch" senden, akzeptiert pilight wohl doch nicht mehr.
pilight-send -p arctec_switch -i 12 -u 1 -t
Geht ja auch nicht (mehr).
Ich habe heute explizit noch mal auf einen alten Stand der Module zurück gewechselt und das "TestDing" probiert. Es geht auch wie erwartet in den alten Versionen nicht ohne dem Attribut brands.
Sorry, ich kann keinen Fehler feststellen!!
Kannst du hier nochmal die alten Module für "ctrl" und "switch" anhängen? Dann teste ich das bei mir auch nochmal. Irgendwie müssen wir dem Fehler ja auf die Schliche kommen, denn vorher ging der Kram ja. :)
Du hast allerdings recht: mit dem brands Attribut funktionieren die Kakus wieder, aber ich garantiere dir, dass ich das Argument vorher nie benutzt hab und es trotzdem funktionierte.
Komisch, komisch...! :/
Ich teste trotzdem gerne die alten Module nochmal!
Nochmal zu meinem Problem:
Zitat von: Weisswurstverkäufer am 14 November 2016, 08:42:09
ich habe ein Problem mit dem Modul - und zwar kann ich immer nur *einmal* schalten. Danach muss ich neu verbinden, um erneut schalten zu können. Empfangen geht allerdings immer. Auch, wenn ich nicht mehr schalten kann.
Der pilight-daemon (pilight-daemon version v7.0) läuft auf einem Raspberry Pi, fhem läuft auf Freeebsd.
Mein pilight_ctrl device hat ignoreProtocol * gesetzt, wenn ich das raus nehme ändert es aber auch nichts.
Die pilight_switch devices scheinen korrekt konfiguriert zu sein (empfangen und einmal schalten funktioniert ja auch), z. B. "elro_800_switch 5 1", "... 5 2" etc.
Ich habe verbose jetzt mal auf 5 gesetzt.
Beim 1. Schalten sieht eigentlich fast alles normal aus:
2016.11.28 10:52:59 5: Steckdose3(Set): on 1 of 1
2016.11.28 10:52:59 4: pilight(Write): RCV (pilight_switch) -> Steckdose3,on
2016.11.28 10:52:59 4: pilight(Write): {"action":"send","code":{"protocol":["elro_800_switch"],"systemcode":6,"unitcode":4,"on":1}}
2016.11.28 10:52:59 5: pilight(SendNonBlocking): queue size 1
2016.11.28 10:52:59 5: pilight(Send): {"action":"send","code":{"protocol":["elro_800_switch"],"systemcode":6,"unitcode":4,"on":1}}
2016.11.28 10:52:59 4: pilight(Send): RCV -> {"status":"success"}
2016.11.28 10:52:59 1: Connection refused from 192.168.42.200:61267
2016.11.28 10:53:00 5: pilight(Parse): RCV -> {"origin":"sender","protocol":"elro_800_switch","message":{"systemcode":6,"unitcode":4,"state":"on"},"repeat":1,"uuid":"0000-b8-27-eb-a356b8"}
2016.11.28 10:53:00 4: pilight(Dispatch): PISWITCH,elro_800_switch,6,4,on,6
2016.11.28 10:53:00 5: pilight dispatch PISWITCH,elro_800_switch,6,4,on,6
2016.11.28 10:53:00 4: pilight_switch_Parse: RCV -> PISWITCH,elro_800_switch,6,4,on,6bis auf das
2016.11.28 10:52:59 1: Connection refused from 192.168.42.200:61267zwischendurch. 192.168.42.200 ist der Rechner (bzw. das FreeBSD jail) auf dem FHEM läuft. Pilight läuft wie gesagt auf einem anderen Rechner.
Ab dem 2. Mal schalten passiert dann das:
2016.11.28 10:53:33 5: Steckdose3(Set): off 1 of 1
2016.11.28 10:53:33 4: pilight(Write): RCV (pilight_switch) -> Steckdose3,off
2016.11.28 10:53:33 4: pilight(Write): {"action":"send","code":{"protocol":["elro_800_switch"],"systemcode":6,"unitcode":4,"off":1}}
2016.11.28 10:53:33 5: pilight(SendNonBlocking): queue size 1
2016.11.28 10:53:33 5: pilight(Write): Blocking Call running - will try it later
2016.11.28 10:53:33 5: pilight(SendNonBlocking): queue size 1
2016.11.28 10:53:33 5: pilight(Write): Blocking Call running - will try it later
2016.11.28 10:53:34 5: pilight(SendNonBlocking): queue size 1
2016.11.28 10:53:34 5: pilight(Write): Blocking Call running - will try it later
2016.11.28 10:53:34 5: pilight(SendNonBlocking): queue size 1die "queue size" wird mit jedem Schaltversuch erhöht. Die Logausgabe läuft so lange, bis ich mich neu mit dem Pi verbinde ("reset").
Vielleicht jetzt jemand eine Idee? :)
Hi Weisswurstverkäufer
Das Senden der 1. Nachricht ist nicht komplett abgeschlossen. Deswegen herhöht sich bei allen weiteren Versuchen die Queue.
So richtig kann ich es mir auch nicht erklären. Versuch mal mit dem Attribut "SendTimeout" z.B. 2,3 etc. das Timeout zu erhöhen!
Zitat von: Risiko am 29 November 2016, 22:51:49
Versuch mal mit dem Attribut "SendTimeout" z.B. 2,3 etc. das Timeout zu erhöhen!
Ändert leider auch nichts. Habe auf bis zu 10 Sekunden erhöht.
Ok, ich habe den Fehler gefunden.
Das Problem lag nicht direkt an dem Pilight Modul, sondern am Blocking.pm bzw. TcpServerUtils.pm(?).
Mein FreeBSD Jail hat(te) keine IP Adresse 127.0.0.1. Irgendetwas scheint aber davon auszugehen dass es diese IP Adresse gibt. Ich habe meinem Jail nun zusätzlich 127.0.0.1 zugewiesen und nun funktioniert es.
Hallo zusammen,
ich bin neu im Fhem Thema und habe nun auch den Fhem und pilight sowie pilight_ctrl zum laufen gebracht 8)
Leider bekomme ich meine REV Funksteckdosen nicht mit pilight_switch ans laufen. Über die Console bekomme ich die Steckdosen wie folgt geschaltet:
pilight-send -p logilink_switch -s 873920 -u 5 -t --on (damit dann 3Steckdose z.B. EIN)
pilight-send -p logilink_switch -s 873920 -u 1 -t --on (damit dann 3Steckdose z.B AUS)
Ich weiss das die Codes nicht so "Sauber" aussehen jedoch war es das einzige wie ich die Dinger ans rennen bekommen habe und auch zuverlässig ein und ausschalten kann.
Update 7.12.16 hier der Edit - mit dem Code.
So habe ich es in FHEM integriert:
den pilight_ctrl so:
define pilight pilight_ctrl localhost:5000 [7.0]
und die Lampe so:
define Flur_Stehlampe_oben pilight_switch logilink_switch 1 5 873920
attr Flur_Stehlampe_oben IODev pilight
Nun meine Frage - könnte mir jemand einen Tip geben wie ich das in Fhem mit pilight_switch ans laufen bekomme?
Vielen Dank im Voraus!
Grüße
shiftedworlds
Hi. Das kann so nicht funktionieren.
Drei Ids werden bei dem Protokoll nicht unterstützt.
Sehes es mir nach meinem Urlaub mal an.
Hi,
Danke für dein Feedback. Ja das mit den 3ids vérstehe ich. Schade das es unter Pilight 7 kein Rev, Rev2 und Rev3 Switch mehr gibt, sonst hätte ich das mal probiert.
Gibt es vielleicht noch weitere Möglichkeiten ohne dir so viel Aufwand zu machen?
Grüße
Shiftedworlds
Zitat von: Risiko am 07 Dezember 2016, 23:22:54
Hi. Das kann so nicht funktionieren.
Drei Ids werden bei dem Protokoll nicht unterstützt.
Sehes es mir nach meinem Urlaub mal an.
Hi,
Ich habe zu dem Thema mit den Rev Switchs noch etwas Hintergrund Info gefunden. Hier der Link:
https://forum.pilight.org/Thread-Work-in-Progress-Rev-Ritter?pid=19374#pid19374
Hast du das mal mit den generic_switch und den rules probiert. Also wenn man pilight-send mit generic_switch funktiniert, dann sollte e mit dem fhem-Modul jetzt schon funktionieren (ungetestet)
Zitat von: Risiko am 17 Dezember 2016, 21:40:22
Hast du das mal mit den generic_switch und den rules probiert. Also wenn man pilight-send mit generic_switch funktiniert, dann sollte e mit dem fhem-Modul jetzt schon funktionieren (ungetestet)
Hallo,
ne habe ich nicht probiert. Liegt aber eher daran das ich es nicht so verstehe was da gemacht wird :-)
Ich habe nochmal etwas probiert und im Log von FHem bekomme ich zudem:
2016.12.19 12:00:06 3: pilight: Unknown code PISWITCH,logilink_switch,873920,3,on,873920, help me!
Ich wäre auch mit 2 Schaltern in Fhem zufrieden, also einen an und einen zum aus schalten. Ich möchte hier ja eh was mit Timern automatisieren. Ich scheitere hier einfach am "generellen" doing. Kann hier evtl. jemand einen Tip geben?
Danke!
Hi ich habe das gleiche Problem mit den logilink_switch Geräten. Ich denke im Notfall bekommt man es irgendwie mit raw zum laufen, aber ist mir im Moment noch zu hoch :-)
Zitat von: shiftedworlds am 19 Dezember 2016, 12:19:17
2016.12.19 12:00:06 3: pilight: Unknown code PISWITCH,logilink_switch,873920,3,on,873920, help me!
Wie sieht den dein define des switchen aus?
Zitat von: shiftedworlds am 19 Dezember 2016, 12:19:17
Ich wäre auch mit 2 Schaltern in Fhem zufrieden, also einen an und einen zum aus schalten. Ich möchte hier ja eh was mit Timern automatisieren. Ich scheitere hier einfach am "generellen" doing. Kann hier evtl. jemand einen Tip geben?
Das wird nicht gehen. Da der Status erst nach dem passenden recieve von pilight geändert wird.
Ich habe noch keine Lösung, hatte aber auch noch keine Zeit darüber nachzudenken.
Hi,
Ich habe da etliche Konfigs in FHEM probiert jedoch leider kein Erfolg. Ich denke das Problem ist folgendes:
Each switch has 1 systemcode, but two unitcodes. The unitcode is either for turning it on or turning the switch off.
Könnte man hier was machen?
Eine besinnliche Weihnachtszeit wünscht,
Shiftedworlds
Hallo.
Leider fällt mir keine sinnvolle Lösung ein. Das Protokoll ist überhaupt nicht kompatibel zu den anderen.
Es sollten aber zwei Schalter gehen. Ansonsten mal bitte mehr Logausgaben bei verbose 5 von pilight_ctrl zeigen.
define Flur_Stehlampe_oben_1 pilight_switch logilink_switch 873920 1
define Flur_Stehlampe_oben_2 pilight_switch logilink_switch 873920 5
Zitat von: Risiko am 23 Dezember 2016, 19:51:43
Hallo.
Leider fällt mir keine sinnvolle Lösung ein. Das Protokoll ist überhaupt nicht kompatibel zu den anderen.
Es sollten aber zwei Schalter gehen. Ansonsten mal bitte mehr Logausgaben bei verbose 5 von pilight_ctrl zeigen.
define Flur_Stehlampe_oben_1 pilight_switch logilink_switch 873920 1
define Flur_Stehlampe_oben_2 pilight_switch logilink_switch 873920 5
Hi,
Danke für deinen Lösungsweg jedoch müsste ich das -t --on auch noch mit rein bekommen, ohne schaltet die Steckdose nicht. Wie kann ich dies noch mit in das Define einbauen?
Grüße
Shiftedworlds
Zitat von: shiftedworlds am 26 Dezember 2016, 07:52:12
Hi,
Danke für deinen Lösungsweg jedoch müsste ich das -t --on auch noch mit rein bekommen, ohne schaltet die Steckdose nicht. Wie kann ich dies noch mit in das Define einbauen?
Grüße
Shiftedworlds
Sorry, verstehe die Frage nicht. Es wird die JSON-API (das was man bei pilight-receive sieht) von pilight verwendet und nicht pilight-send.
Ohne weiter Log's kann ich dir leider auch nicht weiter helfen.
Hallo Zusammen,
super Forum. Habe schon viel mitgenommen. Aber nun streike ich :-(
In meinem Log tummeln sich alle paar Sekunden die Meldungen:
2017.01.08 11:30:05 3: pilight: Unknown code PITEMP,alecto_wx500,138,temperature:128.9,humidity:80,battery:0, help me!
2017.01.08 11:30:06 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:08 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:09 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:11 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:13 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:15 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:15 2: CUL_MAX_SendQueueHandler: Missing ack from 12c3c0 for 0b19044012345612c3c01f2a
2017.01.08 11:30:17 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:18 3: pilight: Unknown code PITEMP,alecto_wx500,138,temperature:128.9,humidity:80,battery:0, help me!
2017.01.08 11:30:19 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:21 3: pilight: Unknown code PITEMP,alecto_wx500,138,temperature:128.9,humidity:80,battery:0, help me!
2017.01.08 11:30:22 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:24 3: pilight: Unknown code PITEMP,alecto_wx500,138,temperature:128.9,humidity:80,battery:0, help me!
2017.01.08 11:30:24 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:401.5, help me!
2017.01.08 11:30:24 3: pilight: Unknown code PITEMP,alecto_wx500,138,temperature:128.9,humidity:80,battery:0, help me!
2017.01.08 11:30:26 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:28 3: pilight: Unknown code PITEMP,alecto_wx500,138,temperature:128.9,humidity:80,battery:0, help me!
2017.01.08 11:30:29 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:31 3: pilight: Unknown code PITEMP,alecto_wx500,138,temperature:128.9,humidity:80,battery:0, help me!
2017.01.08 11:30:33 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:38 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 52, but we need 113. Waiting 61 seconds.
2017.01.08 11:30:39 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:42 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:44 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:45 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:46 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:47 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:47 3: pilight: Unknown code PITEMP,alecto_wx500,138,temperature:128.9,humidity:80,battery:0, help me!
2017.01.08 11:30:48 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:50 3: pilight: Unknown code PITEMP,alecto_wx500,138,temperature:128.9,humidity:80,battery:0, help me!
2017.01.08 11:30:51 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:52 3: pilight: Unknown code PITEMP,alecto_wx500,138,temperature:128.9,humidity:80,battery:0, help me!
2017.01.08 11:30:52 3: pilight: Unknown code PITEMP,alecto_wsd17,4031,temperature:409.4, help me!
2017.01.08 11:30:52 3: pilight: Unknown code PITEMP,alecto_wx500,138,temperature:128.9,humidity:80,battery:0, help me!
2017.01.08 11:30:53 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:55 3: pilight: Unknown code PITEMP,alecto_wx500,138,temperature:128.9,humidity:80,battery:0, help me!
2017.01.08 11:30:56 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:30:58 3: pilight: Unknown code PITEMP,alecto_wx500,138,temperature:128.9,humidity:80,battery:0, help me!
2017.01.08 11:31:00 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:31:10 3: pilight: Unknown code PITEMP,alecto_wsd17,2047,temperature:409.5, help me!
2017.01.08 11:31:10 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:31:11 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
2017.01.08 11:31:12 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:403.1, help me!
2017.01.08 11:31:13 3: pilight: Unknown code PITEMP,alecto_wsd17,3967,temperature:409.5, help me!
2017.01.08 11:31:14 3: pilight: Unknown code PITEMP,alecto_wsd17,4095,temperature:409.5, help me!
Mal ganz davon abgesehen, das ich mit den Werten ohnehin nichts anfangen kann. Bei 5cm Schnee glaube ich einfach nicht an "temperature:409.5" Ist aber auch egal. Ich habe diese doofe Thermometer mit pilight aufgegeben. Spinnt schon immer. So stehen halt 2 verschiedene Sensoren auf der Fensterbank.
Aber ich würde ganz gerne ein leserliches Logfile haben.
Das bekomme ich natürlich irgendwie hin wenn ich mit ignoreProtocol im pilight_ctrl arbeite. Aber bisher funktioniert es nur wenn ich * eintrage. Dann bekomme ich natürlich keine Meldungen meiner Fernbedienungen mehr.
Was muss ich als eintragen um die Protokolle alecto_wx500,alecto_wsd17,alecto_ws1700 zu ignorieren?
Habe schon so einiges ausprobiert. Auch mit Leerzeichen nach dem Komma. Er ignoriert entweder alles oder nichts.
Aktuell steht es so im Editor:
Attributes
ignoreProtocol alecto_wx500,alecto_wsd17,alecto_ws1700
Wie gesagt, so funktioniert es, wie oben beschrieben.
Attributes
ignoreProtocol *
Grüße aus Karlsruhe,
Chris
Zitat von: TheChris1310 am 08 Januar 2017, 11:55:00
Aber bisher funktioniert es nur wenn ich * eintrage. Dann bekomme ich natürlich keine Meldungen meiner Fernbedienungen mehr.
Verstehe ich leider nicht. Was machst du denn mit den Meldungen von der Fernbedienung. Wenn die Fernbedienung für einen Schalter ist, dann lege doch einen pilight_switch an und setze ignoreProtocol auf *
Zitat von: TheChris1310 am 08 Januar 2017, 11:55:00
Was muss ich als eintragen um die Protokolle alecto_wx500,alecto_wsd17,alecto_ws1700 zu ignorieren?
Habe schon so einiges ausprobiert. Auch mit Leerzeichen nach dem Komma. Er ignoriert entweder alles oder nichts.
ignoreProtocol alecto_wx500:*,alecto_wsd17:*,alecto_ws1700:*
Zitat von: Risiko am 08 Januar 2017, 16:06:14
Verstehe ich leider nicht. Was machst du denn mit den Meldungen von der Fernbedienung. Wenn die Fernbedienung für einen Schalter ist, dann lege doch einen pilight_switch an und setze ignoreProtocol auf *
So lauscht der FHEM nur mit und ich sehe zu 80% den Status meiner Steckdosen, ohne das ich die Fernbedienung konfigurieren musste. Ich habe es schon 2 bis 3 Mal versucht, komme aber aktuell mit den Codes der Fernbedienung nicht klar. Aber Recht hast du natürlich. Werde ich irgend wann mal machen :-)
Zitat
ignoreProtocol alecto_wx500:*,alecto_wsd17:*,alecto_ws1700:*
Danke, das war die Lösung! Endlich ruhe im Log :-)
Schönen Sonntag Abend noch!
Edit: Argh, ich hab anscheinend irgendwann mal longpoll ausgestellt - habs wieder auf 1 gesetzt, jetzt ist das Update da.
:-)
=====
Nabend,
Danke für das coole Modul! Ich hatte eigentlich vor einen Signalduino zu bauen, habe Sender und Empfänger dann aber einfach direkt an den Pi angeschlossen und es hat alles direkt geklappt. DANKE!!!
Ich habe nur eine Kleinigkeit: Ich steuere Elro Dosen mit pilight. Das Statusupdate über receive funktioniert auch, aber nur wenn nach einem Page reload. Wenn ich also die FHEM-Deviceseite zu einem pilight_switch offen habe und ihn mit der FB schalte, sehe ich kein Update der Deviceseite. Lade ich die Seite neu, ist das Update da.
Ist das normal, oder hab ich was an meiner FHEM Installation verbastelt?
Viele Grüße
Psy
Kann ich nicht bestätigen. Habe keine Probleme mit der Aktualisierung in FHEMWEB
Hallo,
ich habe seit kurzem folgende 433Mhz Fenstersensoren: http://www.lightinthebox.com/de/gs-iwds07-drahtlosen-intelligenten-tuer-fenster-magnetkontakt_p4766217.html?utm_campaign=cartcross
Diese senden beim öffnen und schließen. Allerdings lassen sich die Signale scheinbar nicht eindeutig einem Pilight-bekannten Protokoll zuordnen.
Aus diesem Grund habe ich versucht diese mit pilight_raw einzubinden.
Definition sieht wie folgt aus:
defmod fenstertest pilight_raw
attr fenstertest IODev PiLight
attr fenstertest offCode 1236 412 412 1236 1236 412 1236 824 412 1236 1236 412 412 1236 412 1236 412 1236 1236 412 1236 412 1236 412 412 1236 412 1236 1236 412 1236 412 412 1236 412 1236 412 1236 412 1236 1236 412 1236 412 1236 412 412 1236 412 14008
attr fenstertest onCode 1242 414 414 1242 1242 414 1242 414 414 1242 1242 414 414 1242 414 1242 414 1242 1242 414 1242 414 1242 414 414 1242 414 1242 1242 414 1242 414 414 1242 414 1242 414 1242 414 1242 1242 414 1242 414 1242 414 414 1242 414 14076
Beim betätigen des Sensors ändert sich der Status allerdings nicht.
Ist pilight_raw nur zum senden von Raw-Codes gedacht?
Gibt es irgendwie eine Möglichkeit Raw-Codes zu empfangen?
(Mit Pimatic scheinen die Fenstersensoren ohne Probleme zu funktionieren: https://forum.pimatic.org/topic/2032/contact04)
Danke für eure Hilfe
Cooler Preis, da wäre ich auch dran interessiert wenn man die zum laufen bringt. Würde die dann gerne mit meinen MAX Thermostaten verwenden.
Gruß Chris
Zitat von: HB86 am 27 Januar 2017, 13:56:35
Ist pilight_raw nur zum senden von Raw-Codes gedacht?
Ja genau.
Zitat von: HB86 am 27 Januar 2017, 13:56:35
Gibt es irgendwie eine Möglichkeit Raw-Codes zu empfangen?
Ist mir nicht bekannt.
Da die Codes ja bekannt sind, lässt sich sicherlich sehr einfach ein Protokoll dafür machen.
Am Besten mal im pilight-Forum danach fragen.
Wenn es ein Protokoll gibt, dann kann ich sicherlich helfen.
Hab mal ins pilight Forum geschrieben. Hoffe es findet sich ne Lösung.
Für den Preis sind die auf jeden Fall unschlagbar.
Moin,
ich versuche gerade meinen inzwischen erfolgreich laufenden pilight für RAW Codes, also Switches, für die ich keinen Module habe, im FHEM einzubauen. Leider stoße ich dabei auf folgende Problematik:
2017.01.28 21:24:28 0: syntax error at ./FHEM/30_pilight_raw.pm line 80, near "){"
syntax error at ./FHEM/30_pilight_raw.pm line 82, near "case "off""
Global symbol "$code" requires explicit package name at ./FHEM/30_pilight_raw.pm line 82, <$fh> line 27.
Global symbol "$code_off" requires explicit package name at ./FHEM/30_pilight_raw.pm line 82, <$fh> line 27.
Global symbol "$updateReading" requires explicit package name at ./FHEM/30_pilight_raw.pm line 82, <$fh> line 27.
syntax error at ./FHEM/30_pilight_raw.pm line 82, near ";}"
Global symbol "$v" requires explicit package name at ./FHEM/30_pilight_raw.pm line 83, <$fh> line 27.
Global symbol "$code" requires explicit package name at ./FHEM/30_pilight_raw.pm line 83, <$fh> line 27.
Global symbol "$v" requires explicit package name at ./FHEM/30_pilight_raw.pm line 83, <$fh> line 27.
syntax error at ./FHEM/30_pilight_raw.pm line 83, near ";}"
./FHEM/30_pilight_raw.pm has too many errors.
Hat jemand eine Idee woran das liegen könnte? Perl ist latest und FHEM auch. Beides auf Raspberry3. Ich schaue mir den Code noch mal an, aber soweit ich das hier gelesen habe sollte der ja funktionieren.
THX,
jens
Hallo peteje,
vermutlich ist libswitch-perl nicht installiert!
Hallo Risiko,
habe die lib nachinstalliert, Switch.pm war aber schon vorhanden, hatte ich auch schon im Pfad. Leider ist das nicht der Fehler. Der Code sieht auch gut aus, Variable lokal deklariert und belegt, Klammerebenen passen.
Ich meine nicht switch.pm sondern das perl switch.
Zitat von: Risiko am 28 Januar 2017, 12:11:30
Da die Codes ja bekannt sind, lässt sich sicherlich sehr einfach ein Protokoll dafür machen.
Am Besten mal im pilight-Forum danach fragen.
Wenn es ein Protokoll gibt, dann kann ich sicherlich helfen.
Protokoll dazu ist in Arbeit: https://forum.pilight.org/Thread-gs-iwds07-window-sensor?pid=20456#pid20456
Habs gerade getestet, funktioniert soweit. Außer dass open und close noch vertauscht sind.
OK. Wenn das Protokoll sowie die ID's (units) bekannt sind und fest stehen, kann ich das aufnehmen.
Zitat von: Risiko am 01 Februar 2017, 20:38:35
OK. Wenn das Protokoll sowie die ID's (units) bekannt sind und fest stehen, kann ich das aufnehmen.
Mittels pilight-receive siehts so aus:
"message": {
"unit": 13125,
"battery": 1,
"state": "opened"
},
"origin": "receiver",
"protocol": "GW-iwds07",
"uuid": "0000-b8-27-eb-3b0b25",
"repeats": 12
Gibt nur Units, die sind alle 5 stellig, bei mir z.B.: 60931, 49525, 13125, ...
Zitat von: Risiko am 01 Februar 2017, 20:38:35
OK. Wenn das Protokoll sowie die ID's (units) bekannt sind und fest stehen, kann ich das aufnehmen.
Das Protokoll steht: https://github.com/wo-rasp/pilight/tree/dev_gs_iwds07
Wäre echt super wenn du das hinzufügen könntest.
Weitere Infos im Pilight-Forum: https://forum.pilight.org/Thread-gs-iwds07-window-sensor
Vielen Dank schonmal
Zitat von: HB86 am 09 Februar 2017, 15:42:50
Das Protokoll steht: https://github.com/wo-rasp/pilight/tree/dev_gs_iwds07
Wäre echt super wenn du das hinzufügen könntest.
Weitere Infos im Pilight-Forum: https://forum.pilight.org/Thread-gs-iwds07-window-sensor
Vielen Dank schonmal
Kann das Protokoll bitte irgendjemand einbinden. :-\
Noch eine Bitte:
Die Temperatursensoren BMP180 und BMP085 laufen ja auch bereits unter pilight und lassen sich einfach ansprechen.
Ich habe dazu in der 10_pilight_ctrl.pm folgende 2 Zeilen (nach Zeile 860) ergänzt:
case m/bmp085/ {$protoID = 4;}
case m/bmp180/ {$protoID = 4;}
Und es funzt ohne weitere Änderungen/Ergänzungen einwandfrei!
Ein Device dazu anlegen geht so (Vorschlag):
define BMP180 pilight_temp bmp180 0x77
attr BMP180 IODev PilightCtrl
attr BMP180 event-on-change-reading pressure,temperature
attr BMP180 stateFormat T:temperature °C / P:pressure hPa
Mit dem I2C-Modul lief es zwar auch, aber warum noch mal 2 Extra-Module laufen lassen, wenn pilight_ctrl und pilight_temp sowieso schon am Werkeln sind...?
hab jetzt auch das Protokoll gs-iwds07 in der Form in die pilight_ctrl eingebunden:
case m/GS-iwds07/ {$protoID = 3;}
Weiß aber leider nicht genau wie ich die Sensoren konfigurieren muss.
FHEM-Log liefert:
PiLight: Unknown code PICONTACT,GS-iwds07,58285,58285,closed, help me
Meine Definition sieht so aus:
defmod Fenster_WZ1 pilight_contact GS-iwds07 58285 58285
attr Fenster_WZ1 IODev PiLight
..funktioniert aber leider nicht :(
Hallo, ich habe das Problem, dass das Pilightmodul nach einem Neustart von FHEM nicht mehr funktioniert, bzw. muss ich nach einem "shutdown restart" den pilight-daemon von Hand neu starten.
Hat schon jemand so ein Problem gehabt?
(ich betreibe Pilight auf einem Arduino Nano am Raspberry Pi)
Falls du meinst das pilight_ctrl zwischendurch auf disconnect steht und erst nach einem "service pilight stop" "service pilight start" wieder reconnected kann ja das Problem habe ich auch.
Habe es gelöst mit einem DOIF das den state von pilight_ctrl überwacht und ggf die nötigen befehle ausführt
genau, das mein ich...mit einem DOIF klappts wieder, danke.
So sieht mein DOIF aus
define di_pilight_reset DOIF ([Funken] eq "disconnected" and [+120]) ({system ("sudo service pilight stop" )}) ({system ("sudo service pilight start" )}) (set Funken reset)
Und attr di_pilight_reset wait 0,2
Vielleicht hilft es jemanden mit dem selben Problem
Zitat von: HB86 am 05 März 2017, 18:47:30
hab jetzt auch das Protokoll gs-iwds07 in der Form in die pilight_ctrl eingebunden:
case m/GS-iwds07/ {$protoID = 3;}
Weiß aber leider nicht genau wie ich die Sensoren konfigurieren muss.
FHEM-Log liefert:
PiLight: Unknown code PICONTACT,GS-iwds07,58285,58285,closed, help me
Meine Definition sieht so aus:
defmod Fenster_WZ1 pilight_contact GS-iwds07 58285 58285
attr Fenster_WZ1 IODev PiLight
..funktioniert aber leider nicht :(
Kann niemand helfen das Modul einzubinden? :(
Wäre auch schön wenn sich hier der Modul-Entwickler mal wieder zu Wort melden würde.
Hallo,
ich habe mehrere pilight_switch konfiguriert und sie schalten auch alle einwandfrei. Leider bleibt der State immer auf "defined".
Kann mir bitte jemand erklären, woran dass liegt und wie man es löst? Anscheinend hatten schon andere ja auch schon das Problem.
Edit:
Habe das Problem gelöst. In der CommandRef ist ein Tippfehler:
Example: brands archtech:kaku
Mit "arctech" klappt es dann auch.
Ich bin verzweifelt... lange habe ich gebraucht um nachzuvollziehen, dass die "/etc/pilight/config.json" einen manuellen Eintrag für Port benötigt, aber das klappt nun auch.
Neues Problem zu dem ich keine Lösung finde: meine 433MHz Steckdose schalte ich von der Shell aus mit
<an> pilight-send -p daycom -i 53 -s 7488 -u 4 -t
<aus> pilight-send -p daycom -i 53 -s 7488 -u 3 -t
d.h. an und aus unterscheiden sich in der <unit>.
define pilight pilight_ctrl localhost:6000 [7.0]
define Steckdose_A_on pilight_switch daycom 53 4 7488
attr Steckdose_A_on IODev pilight
define Steckdose_A_off pilight_switch daycom 53 3 7488
attr Steckdose_A_off IODev pilight
Wie lässt sich das bei der Definition des "gewöhnliches" Schalters berücksichtigen?
Vielen Dank.
Sensibelchen
PS: Ich habe mir jetzt mit Dummy Schalter und Notificatons geholfen, aber vielleicht geht es ja sauberer...
Hallo ich habe Fenster Kontakte von denen ich folgendes in Fhem EventMonitor angezeigt bekomme
017-03-27 14:45:59 pilight_ctrl Funken UNKNOWNCODE PISCREEN,arctech_screen_old,23,13,up
Allerdings bekomme ich sie nicht mit
define Wohnzimmer_Fenster pilight_switch arctech_screen_old 23 13
Gibt es ne Möglichkeit diese zu integrieren?
Leider scheint der Modulentwickler hier nicht mehr aktiv zu sein :(
Vielleicht findet sich ja jemand der das nötige Know-How hat um das Modul weiter zu entwickeln.
Sorry,
war längere Zeit dienstlich abwesend.
Werde versuchen die Sachen in nächster Zeit aufzuarbeiten.
Risiko
Hallo,
ich habe ein dummes Problem mit Pilight:
Ich habe mir einen zweiten Raspberry mit den selben Sendern/Empfängern gekauft und möchte den zum laufen bringen.
Habe Pilight laut deren guide installiert. Per Konsole kann ich auch Lampen schalten etc.
In FHEM habe ich die erste Lampe und das ctrl-device so definiert:
define pilight pilight_ctrl localhost:5000 7.0
attr pilight verbose 5
define SternLampe pilight_switch elro_800_switch 31 1
attr SternLampe IODev pilight
attr SternLampe alias Stern
attr SternLampe room Homekit,WohnzimmerAber es passiert einfach NICHTS!
Interessanterweise: wenn ich das "localhost" im ctrl-device gegen die IP meines anderen Raspberrys ersetze den ich vor einem halben Jahr aufgesetzt habe und auf dem alles läuft, dann funktioniert es auch hier, also muss irgendeine dumme Pilight-Config falsch sein. Aber welche? :(
Das folgende steht dann im Log:
Zitat2017.04.04 22:09:50 5: Cmd: >set SternLampe off<
2017.04.04 22:09:50 5: SternLampe(Set): off 1 of 1
2017.04.04 22:09:50 4: pilight(Write): RCV (pilight_switch) -> SternLampe,off
2017.04.04 22:09:50 4: pilight(Write): {"action":"send","code":{"protocol":["elro_800_switch"],"systemcode":31,"unitcode":1,"off":1}}
2017.04.04 22:09:50 5: pilight(SendNonBlocking): queue size 1
2017.04.04 22:09:50 4: BlockingCall (pilight_ctrl_Send): created child (1034), uses telnetForBlockingFn_1491336558 to connect back
2017.04.04 22:09:50 4: WEB: /fhem?cmd.SternLampe=set%20SternLampe%20off&room=Wohnzimmer&room=Wohnzimmer&XHR=1&fwcsrf=csrf_235239318560161&fw_id=167 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.04.04 22:09:50 5: pilight(Send): {"action":"send","code":{"protocol":["elro_800_switch"],"systemcode":31,"unitcode":1,"off":1}}
2017.04.04 22:09:50 4: pilight(Send): RCV -> {"status":"success"}
2017.04.04 22:09:50 4: Connection accepted from telnetForBlockingFn_1491336558_127.0.0.1_59050
2017.04.04 22:09:50 5: Cmd: >{BlockingStart('2')}<
2017.04.04 22:09:50 5: Cmd: >{pilight_ctrl_SendDone('pilight|1')}<
2017.04.04 22:09:50 4: pilight(SendDone): message successfully send
2017.04.04 22:09:50 5: pilight(Parse): RCV -> {"origin":"sender","protocol":"elro_800_switch","message":{"systemcode":31,"unitcode":1,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-93904a"}
2017.04.04 22:09:50 5: Starting notify loop for pilight, 1 event(s), first is rcv_raw: {"origin":"sender","protocol":"elro_800_switch","message":{"systemcode":31,"unitcode":1,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-93904a"}
2017.04.04 22:09:50 5: createNotifyHash
2017.04.04 22:09:50 5: End notify loop for pilight
2017.04.04 22:09:50 4: pilight(Dispatch): PISWITCH,elro_800_switch,31,1,off,31
2017.04.04 22:09:50 5: pilight: dispatch PISWITCH,elro_800_switch,31,1,off,31
2017.04.04 22:09:50 4: pilight_switch_Parse: RCV -> PISWITCH,elro_800_switch,31,1,off,31
Ich verstehe einfach nicht, warum da nichts kommt.
Ich habe auch schon vom guten auf den schlechten Raspberry versucht Pilight zu kopieren, genauer gesagt die Ordner "/etc/pilight", "/usr/local/share/pilight/" und "/usr/local/lib/pilight/", neugestartet und trotzdem funktioniert es nicht.
Hat jemand einen Tipp für mich? :(
Die Zeile Port 5000 hast du aber in der pilight configuration hinzugefügt oder
Moin,
Evtl sonst noch die firewall ausschalren/konfigurieren?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Firewall hat der Pi keine und Port 5000 habe ich eingestellt.
Es könnte aber laut Tipp aus dem Pilight-Forum bekommen, dass es durch Pilights "adhoc" Modus sein kann, dass der 2. Pi die Befehle einfach über den 1. Pi per Funk abgesetzt hat. Interessanterweise funktioniert nämlich nichts (auch zB nicht wiringPi + rcswitch Pi) auf dem 2. RPi wenn ich den 1. aus mache...
Und noch interessanter ist, dass das Empfangen PERFEKT funktioniert!
Ich teste da mal etwas herum! Melde mich aber auf jeden Fall noch mit dem Ergebnis!
Aber falls noch jemand Ideen hat bin ich natürlich dankbar! :)
Hallo,
ist es vielleicht möglich das Protokoll für die Livolo Schalter hinzuzufügen?
https://wiki.pilight.org/doku.php/livolo_switch_v7_0 (https://wiki.pilight.org/doku.php/livolo_switch_v7_0)
Damit könnte man dann wohl auch diese Schalter ansteuern:
http://www.ebay.de/itm/302240949882?_trksid=p2057872.m2749.l2649&var=601082974102&ssPageName=STRK%3AMEBIDX%3AIT (http://www.ebay.de/itm/302240949882?_trksid=p2057872.m2749.l2649&var=601082974102&ssPageName=STRK%3AMEBIDX%3AIT)
Den habe ich mir mal zum Testen bestellt und würde ihn natürlich auch gern in Fhem integrieren.
Wenn das dann gut funktioniert, wäre es eine günstige Alternative vorhandene Deckenlampen einzubinden.
Gruß
Riverghost
Zitat von: HB86 am 13 März 2017, 14:26:57
Kann niemand helfen das Modul einzubinden? :(
Wäre auch schön wenn sich hier der Modul-Entwickler mal wieder zu Wort melden würde.
Hallo HB86,
deine Änderung ist wohl nicht korrekt. Heißt das Protokoll nun 'GW-iwds07' oder 'GS-iwds07'
Ich habe GW-iwds07 aufgenommen!
Zitat von: nageniil am 02 März 2017, 22:42:12
Noch eine Bitte:
Die Temperatursensoren BMP180 und BMP085 laufen ja auch bereits unter pilight und lassen sich einfach ansprechen.
Ich habe dazu in der 10_pilight_ctrl.pm folgende 2 Zeilen (nach Zeile 860) ergänzt:
case m/bmp085/ {$protoID = 4;}
case m/bmp180/ {$protoID = 4;}
Und es funzt ohne weitere Änderungen/Ergänzungen einwandfrei!
Ich habe die Protokolle mit aufgenommen.
Danke.
Zitat von: Tueftler1983 am 27 März 2017, 14:55:20
Hallo ich habe Fenster Kontakte von denen ich folgendes in Fhem EventMonitor angezeigt bekomme
017-03-27 14:45:59 pilight_ctrl Funken UNKNOWNCODE PISCREEN,arctech_screen_old,23,13,up
Allerdings bekomme ich sie nicht mit
define Wohnzimmer_Fenster pilight_switch arctech_screen_old 23 13
Gibt es ne Möglichkeit diese zu integrieren?
Hallo Tueftler1983,
screen ist kein Switch! Das Protokoll wird glaube verwendet, wenn man die Taste gedrückt hält.
Du kannst es mal mit pilight_dimmer probieren. Hier ist eine Logik für Screen mit up und down eingebaut.
Zitat von: Riverghost am 08 April 2017, 11:20:54
Hallo,
ist es vielleicht möglich das Protokoll für die Livolo Schalter hinzuzufügen?
https://wiki.pilight.org/doku.php/livolo_switch_v7_0 (https://wiki.pilight.org/doku.php/livolo_switch_v7_0)
Gruß
Riverghost
Könnte schon ohne Anpassungen funktionieren ;)
Das muss GS-iwds07 heißen ..
Siehe pilight forum
Hab das gerad mal selber umbenannt in pilight_ctrl allerdings funktioniert das modul so nicht
Meine Definition sieht so aus:
DEF GS-iwds07 58285
Zitat von: Risiko am 08 April 2017, 19:13:17
Hallo HB86,
deine Änderung ist wohl nicht korrekt. Heißt das Protokoll nun 'GW-iwds07' oder 'GS-iwds07'
Ich habe GW-iwds07 aufgenommen!
Kannst du das "GS-iwds07" Protokoll bitte nochmal überprüfen, funktioniert leider noch nicht.
Hallo zusammen,
ich habe es jetzt hinbekommen meinem 1byOne Bewegungsmelder als Pilight Protokoll zu integrieren. Ich habe den Melder als Pilightswitch angelegt und sehe fleißig Nachrichten eintrudeln.
Allerdings sendet der Bewegungsmelder nur den State on, es erfolgt kein Zustandswechsel. Wie kann ich nun per DOIF auswerten, ob der Sensor was gesendet hat und darauf reagieren? Es gibt ja den MSGCNT aber wie werte ich den aus?
Habe es mit einem Notify gemacht
Bewegungsmelder:on set Bewegung on;sleep 60;set Bewegung off;set Bewegungsmelder off
Zitat von: HB86 am 19 April 2017, 13:04:07
Kannst du das "GS-iwds07" Protokoll bitte nochmal überprüfen, funktioniert leider noch nicht.
Könntest du mal bitte eine Ausschrift von pilight-receiver posten. Da sehe ich am Besten was los ist.
Zitat von: derchrome am 20 April 2017, 18:40:19
Hallo zusammen,
ich habe es jetzt hinbekommen meinem 1byOne Bewegungsmelder als Pilight Protokoll zu integrieren. Ich habe den Melder als Pilightswitch angelegt und sehe fleißig Nachrichten eintrudeln.
Allerdings sendet der Bewegungsmelder nur den State on, es erfolgt kein Zustandswechsel. Wie kann ich nun per DOIF auswerten, ob der Sensor was gesendet hat und darauf reagieren? Es gibt ja den MSGCNT aber wie werte ich den aus?
Hallo. Ich halte einen Switch hier nicht für sinnvoll. Meiner Meinung nach ist ein Kontakt da besser geeignet. Man kann ja nicht senden!
Ggf. kann ich auch ein separates Modul für einen Bewegungsmelder machen. Wie sieht denn das Protokoll aus (Ausschrift von pilight_receive)?
Zitat von: Risiko am 21 April 2017, 20:21:03
Könntest du mal bitte eine Ausschrift von pilight-receiver posten. Da sehe ich am Besten was los ist.
{
"message": {
"unit": 58285,
"battery": 1,
"state": "opened"
},
"origin": "receiver",
"protocol": "GS-iwds07",
"uuid": "0000-b8-27-eb-3b0b25",
"repeats": 15
}
{
"message": {
"unit": 58285,
"battery": 1,
"state": "closed"
},
"origin": "receiver",
"protocol": "GS-iwds07",
"uuid": "0000-b8-27-eb-3b0b25",
"repeats": 1
Für mehr Details kannst du ja auch mal im pilight-Forum schauen: https://forum.pilight.org/Thread-gs-iwds07-window-sensor
Zitat von: HB86 am 22 April 2017, 11:17:42
Für mehr Details kannst du ja auch mal im pilight-Forum schauen: https://forum.pilight.org/Thread-gs-iwds07-window-sensor
Ich habe den Protokollnamen angepasst. Es müsst eigentlich gehen. Wenn nicht bitter verbose auf 5 stellen und mir die Logs zeigen.
Zitat von: Risiko am 22 April 2017, 13:37:22
Ich habe den Protokollnamen angepasst. Es müsst eigentlich gehen. Wenn nicht bitter verbose auf 5 stellen und mir die Logs zeigen.
2017.04.22 13:46:58 5: PiLight(Parse): RCV -> {"message":{"unit":58285,"battery":1,"state":"closed"},"origin":"receiver","protocol":"GS-iwds07","uuid":"0000-b8-27-eb-3b0b25","repeats":13}
2017.04.22 13:46:58 5: PiLight: dispatch PICONTACT,GS-iwds07,58285,58285,closed
2017.04.22 13:46:58 4: pilight_contact_Parse (PiLight): RCV -> PICONTACT,GS-iwds07,58285,58285,closed
2017.04.22 13:46:58 3: PiLight: Unknown code PICONTACT,GS-iwds07,58285,58285,closed, help me!meine Definition:
DEF GS-iwds07 58285
Funktioniert noch nicht
Hmm du meinst als Contact? Ich hatte ein Protokoll als Switch erstellt. Das funktioniert auch soweit. Wie wandle ich das denn in ein Contact Protokoll um?
Ich habe mittlerweile auch meine Türklingel in FHEM via neuem Protokoll in Pilight integriert. Wenn man weiß wie es geht ist es eigentlich ganz einfach. Besonders dann wenn es nur auf eine eindeutige Identifierung, aber nicht auf die tatsächlichen Daten ankommt. Ich glaube mein nächstes Projekt, das Funkthermometer vom Aldi wird da schon schwieriger...
Gibt es eigentlich schon ein Tutorial zum Thema erstellen von neuen Protokollen und deren Integration in FHEM? Wenn nicht könnte man ja mal eins aufsetzen.
Gesendet von meinem XT1562 mit Tapatalk
Zitat von: HB86 am 22 April 2017, 13:49:13
meine Definition:
DEF GS-iwds07 58285
Funktioniert noch nicht
Problem erkannt. Es liegt an der Groß- Kleinschreibung des Protokolls. Wieder eine Besonderheit! Hatte bis jetzt immer Kleinschreibung voraus gesetzt und würde das auch so beibehalten wollen
Könntest du bitte mal zwei Varianten testen.
1. Nur die beiliegende 10_pilight_ctrl ersetzen - hier wird alles in Kleinbuchstaben gewandelt
2. Die Version 10_pilight_ctrl vom Repository verwenden und 10_pilight_contact ersetzen. Hier bleibt alles so mit Groß-Kleinschreibung,
Danke.
Zitat von: derchrome am 22 April 2017, 21:29:03
Hmm du meinst als Contact? Ich hatte ein Protokoll als Switch erstellt. Das funktioniert auch soweit. Wie wandle ich das denn in ein Contact Protokoll um?
Einfach statt on/off eben opened/closed. Es gibt in pilight bereits eine passende Kategorie 'Motion Sensors' https://wiki.pilight.org/doku.php/protocols#wireless_motion_sensors
Leider sind die Jungs dort nicht konsequent: Arctech Motion verwendet on/off und EV1527 Motion opened/closed.
Meiner Meinung nach ist ein Switch falsch!
Zitat von: derchrome am 22 April 2017, 21:29:03
Gibt es eigentlich schon ein Tutorial zum Thema erstellen von neuen Protokollen und deren Integration in FHEM? Wenn nicht könnte man ja mal eins aufsetzen.
Das ist ein Thema für pilight. Wenn es ein neues Protokoll gibt, dann nehme ich es für FHEM einfach mit in die Liste auf entsprechend Kategorie auf. Blöd ist nur, wenn die Jungs sich immer wieder was Neues einfallen lassen, wie zuletzt Groß-Kleinschreibung, keine id, etc.
Zitat von: Risiko am 23 April 2017, 14:22:53
Problem erkannt. Es liegt an der Groß- Kleinschreibung des Protokolls. Wieder eine Besonderheit! Hatte bis jetzt immer Kleinschreibung voraus gesetzt und würde das auch so beibehalten wollen
Könntest du bitte mal zwei Varianten testen.
1. Nur die beiliegende 10_pilight_ctrl ersetzen - hier wird alles in Kleinbuchstaben gewandelt
2. Die Version 10_pilight_ctrl vom Repository verwenden und 10_pilight_contact ersetzen. Hier bleibt alles so mit Groß-Kleinschreibung,
Danke.
Variante 1 funktioniert nicht. Log:
2017.04.23 23:04:32 1: reload: Error:Modul 10_pilight_ctrl deactivated:
Bareword "proto" not allowed while "strict subs" in use at ./FHEM/10_pilight_ctrl.pm line 755.
2017.04.23 23:04:32 0: Bareword "proto" not allowed while "strict subs" in use at ./FHEM/10_pilight_ctrl.pm line 755.Variante 2 funktioniert ohne Probleme :)
Besteht die Möglichkeit den battery Wert noch einzubinden?
OK. Habe Variante 2 eingecheckt und Batteriewert als Reading mit aufgenommen
Jetzt habe ich den Sensor im Protokoll als Contact definiert. Es kommt nun aber kein Reading mehr?! Der Bewegungsmelder steht auf "initialized, die Nachrichten werden hochgezählt , aber es kommt kein Reading... Hat jemand eine Idee was schief gelaufen sein könnte?
Hi. Das neue Protokoll ist noch nicht bekannt. Stelle mal bitte von pilight_ctrl verbose auf 5 und schaue im Log.
Zitat von: HB86 am 02 Februar 2017, 12:26:02
Mittels pilight-receive siehts so aus:
"message": {
"unit": 13125,
"battery": 1,
"state": "opened"
},
"origin": "receiver",
"protocol": "GW-iwds07",
"uuid": "0000-b8-27-eb-3b0b25",
"repeats": 12
Gibt nur Units, die sind alle 5 stellig, bei mir z.B.: 60931, 49525, 13125, ...
Hi, was hast du denn für einen Empfänger? Ich habe aktuell den RXB6 im Einsatz, der direkt über die GPOI's am Raspi hängt und zuverlässig meine Funksteckdosen empfängt, allerdings empfängt er bei pilight-receive nix von den Fenstersensoren :(
Zitat von: disastah am 09 Mai 2017, 17:00:39
Hi, was hast du denn für einen Empfänger? Ich habe aktuell den RXB6 im Einsatz, der direkt über die GPOI's am Raspi hängt und zuverlässig meine Funksteckdosen empfängt, allerdings empfängt er bei pilight-receive nix von den Fenstersensoren :(
Hallo,
ich nutze diese Empfänger und Sender: https://www.amazon.de/gp/product/B00ATZV5EQ/ref=oh_aui_search_detailpage?ie=UTF8&psc=1
Sender und Empfänger hängen bei mir auch direkt an den GPIOs des Raspi.
Am Empfänger hab ich diese Antenne dran: https://www.amazon.de/gp/product/B00JG4XNBY/ref=oh_aui_search_detailpage?ie=UTF8&psc=1
Nutzt du die gleichen Fenstersensoren wie ich? (http://www.lightinthebox.com/de/gs-iwds07-drahtlosen-intelligenten-tuer-fenster-magnetkontakt_p4766217.html?utm_campaign=cartcross)
Ich würde gerne den Status meiner Fensterkontakte aller 30min aktualisieren, allerdings funktioniert event-min-interval mit pilight-contact scheinbar nicht.
Hat jemand ähnliche Erfahrungen?
Meine Definition sieht so aus:
defmod Fenster_Bad pilight_contact GS-iwds07 60931
attr Fenster_Bad IODev PiLight
attr Fenster_Bad event-min-interval .*:1800
attr Fenster_Bad event-on-change-reading state
Zitat von: HB86 am 10 Mai 2017, 09:40:02
Hallo,
ich nutze diese Empfänger und Sender: https://www.amazon.de/gp/product/B00ATZV5EQ/ref=oh_aui_search_detailpage?ie=UTF8&psc=1
Sender und Empfänger hängen bei mir auch direkt an den GPIOs des Raspi.
Am Empfänger hab ich diese Antenne dran: https://www.amazon.de/gp/product/B00JG4XNBY/ref=oh_aui_search_detailpage?ie=UTF8&psc=1
Diesen Empfänger/Sender hatte ich zuerst, war aber mit deren Reichweite und Zuverlässigkeit nicht so zufrieden, sodass ich mir dann diese gekauft habe:
https://www.amazon.de/gp/product/B00YMMFJJO/ref=oh_aui_detailpage_o07_s00?ie=UTF8&psc=1
Eigentlich bin ich auch mit denen mehr als zufrieden! Ich kann mal schauen, ob ich die alten noch finde und werd es dann mit denen mal testen
Zitat von: HB86 am 10 Mai 2017, 09:40:02
Nutzt du die gleichen Fenstersensoren wie ich? (http://www.lightinthebox.com/de/gs-iwds07-drahtlosen-intelligenten-tuer-fenster-magnetkontakt_p4766217.html?utm_campaign=cartcross)
ja genau diese hab ich mir auch bestellt (2 Stück) aber bei beiden kommt nix an :(
weißt du, wozu auf der Rückseite dieser Schalter ist, der schließt, wenn man den kleinen Deckel dran macht?
Bis dahin und thx für dein Antwort :)
Der kleine Schalter ist ein Sabotage kontakt. Sollte auch eine Meldung generieren
Zitat von: Tueftler1983 am 10 Mai 2017, 14:20:49
Der kleine Schalter ist ein Sabotage kontakt. Sollte auch eine Meldung generieren
So ist es!
Das du nix empfängst liegt glaube ich nicht am Empfänger.
Das "GS-iwds07" Protocol ist nicht offiziell in pilight enthalten, das muss manuell installiert werden.
Siehe: https://manual.pilight.org/en/installation "Manually Compiled Version"
Als Quelle für das Protocol musst du https://github.com/wo-rasp/pilight/tree/dev_gs_iwds07 nutzen.
Zitat von: HB86 am 10 Mai 2017, 14:26:10
So ist es!
Das du nix empfängst liegt glaube ich nicht am Empfänger.
Das "GS-iwds07" Protocol ist nicht offiziell in pilight enthalten, das muss manuell installiert werden.
Siehe: https://manual.pilight.org/en/installation "Manually Compiled Version"
Als Quelle für das Protocol musst du https://github.com/wo-rasp/pilight/tree/dev_gs_iwds07 nutzen.
Ah ok - dachte es wäre schon drin - meine Frage ist jetzt nur, wie / wo ich die Quelle hinzufügen muss?
Danke!
Zitat von: disastah am 10 Mai 2017, 15:50:40
Ah ok - dachte es wäre schon drin - meine Frage ist jetzt nur, wie / wo ich die Quelle hinzufügen muss?
Danke!
du musst die zeile:
root@pilight:~# git clone --depth 5 -b [branch] https://www.github.com/pilight/pilight.gitersetzen durch:
root@pilight:~# git clone --depth 5 -b dev_gs_iwds07 https://www.github.com/wo-rasp/pilight.git
Zitat von: HB86 am 10 Mai 2017, 15:54:35
du musst die zeile:
root@pilight:~# git clone --depth 5 -b [branch] https://www.github.com/pilight/pilight.git
ersetzen durch:
root@pilight:~# git clone --depth 5 -b dev_gs_iwds07 https://www.github.com/wo-rasp/pilight.git
Werd ich gleich nachher mal testen - bleibt das Protokoll auch nach einem regulären apt-get update/upgrade drin?
Besten Dank!
Zitat von: disastah am 10 Mai 2017, 16:37:38
bleibt das Protokoll auch nach einem regulären apt-get update/upgrade drin?
Nein, leider nicht.
Zitat von: HB86 am 10 Mai 2017, 16:43:12
Nein, leider nicht.
Ok, dann werde ich es erstmal aus der source.list raus nehmen.
So aber danke, hat alles funktioniert und läuft jetzt auch bei mir! 8)
Zitat von: disastah am 11 Mai 2017, 14:30:49
So aber danke, hat alles funktioniert und läuft jetzt auch bei mir! 8)
Freut mich. :)
Ich bin mit den Fenstersensoren bis jetzt vollkommen zufrieden.
Melden sich immer zuverlässig und sind für der Preis ist einfach unschlagbar.
Hallo,
mein pilight-Modul will leider noch nicht so ganz wie ich möchte:
Für eine kurze Zeit ist eine Verbindung da, bricht dann aber ab. Oder ist das normal?
[code]2017.05.15 13:26:09 3 : Opening myPilight device 192.168.0.49:85
2017.05.15 13:26:09 3 : myPilight device opened
2017.05.15 13:26:21 1 : 192.168.0.49:85 disconnected, waiting to reappear (myPilight)
2017-05-15 13:26:21 pilight_ctrl myPilight DISCONNECTED[/code]
Oder ist das normal. dass die Verbindung abbricht? Per Browser komme ich zu jederzeit auf die GUI (.49:85) von pilight bei mir drauf.
Hier das Listing:
Internals:
API 6.0
DEF 192.168.0.49:85
DevIoJustClosed 1
DeviceName 192.168.0.49:85
NAME myPilight
NR 1066
NTFY_ORDER 50-myPilight
PARTIAL
RETRY_INTERVAL 60
STATE disconnected
TYPE pilight_ctrl
Readings:
2017-05-15 14:18:02 state disconnected
Helper:
CHECK 0
CON disconnected
NEXT_TRY 1494850742
sendQueue:
whiteList:
arctech_switch_old:27
Attributes:
room Pilight,System
"set myPilight reset" setzt ihn kurz auf "opened", dann wieder disconnected.
Wäre klasse, wenn ich einen Hinweis bekommen könnte.
Grüße & Danke
Thomas
Hast du den Port 85 auch in der pilight configuration eingetragen?
klar :-)
{
"devices": {},
"rules": {},
"gui": {},
"settings": {
"log-level": 6,
"pid-file": "/var/run/pilight.pid",
"log-file": "/var/log/pilight.log",
"webserver-enable": 1,
"webserver-root": "/usr/local/share/pilight/",
"webserver-http-port": 85,
"webserver-cache": 1
},
"hardware": {
"433gpio": {
"sender": 0,
"receiver": 2
}
},
"registry": {
"pilight": {
"firmware": {
"version": 38639,
"lpf": 217970,
"hpf": 90
},
"version": {
"current": "7.0"
}
}
}
}
pilight-receive und pilight-send -p kaku_switch -i 123456 -u 0 -t funktionieren via Console
Für fhem mußt du eine extra Zeile anlegen, mit
"port": 86
Web port und port für fhem sind getrennt
So sollte es danach aussehen: die portnummer die du hier bei port einträgst muss dann auch in Fhem eingetragen werden
{
"devices": {},
"rules": {},
"gui": {},
"settings": {
"log-level": 6,
"pid-file": "/var/run/pilight.pid",
"log-file": "/var/log/pilight.log",
"webserver-enable": 1,
"webserver-root": "/usr/local/share/pilight/",
"webserver-http-port": 85,
"port": 86
"webserver-cache": 1
},
"hardware": {
"433gpio": {
"sender": 0,
"receiver": 2
}
},
"registry": {
"pilight": {
"firmware": {
"version": 38639,
"lpf": 217970,
"hpf": 90
},
"version": {
"current": "7.0"
}
}
}
}
vielen lieben Dank! Jetzt klappt es. Habe es bestimmt überlesen mit dem speziellen Port.
Grüße
Thomas
Das freut mich.
Herrje kommt da viel rein. Gibt es in dem Modul so eine Art Autocreate wie bei der ESP Bridge oder bei den CUL's?
Glaube ich nicht wäre aber auch nicht gut bei soviel 433 MHz Geräten die so im Umkreis schwirren. Außerdem gibt es auch viele fehlsignale
habe hier hoffentlich mein Signal identifiziert:
2017-05-15 16:33:55 pilight_ctrl myPilight rcv_raw: {"message":{"id":27,"unit":1,"state":"up"},"origin":"receiver","protocol":"arctech_screen_old","uuid":"0000-b8-27-eb-88e491","repeats":1}
dann habe ich das Device so angelegt:
define stripe_v2 pilight_switch arctech_screen_old 27 1
--> Leider schaltet sich nichts.
Was mache ich mit solchen Zeilen? @UNKNOWNCODE PISWITCH
2017-05-15 16:33:55 pilight_ctrl myPilight rcv_raw: {"message":{"systemcode":14,"unitcode":18,"state":"on"},"origin":"receiver","protocol":"silvercrest","uuid":"0000-b8-27-eb-88e491","repeats":1}
2017-05-15 16:33:55 pilight_ctrl myPilight UNKNOWNCODE PISWITCH,silvercrest,14,18,on,14
2017.05.15 16:33:55 3 : myPilight: Unknown code PISWITCH,silvercrest,14,18,on,14, help me!
2017-05-15 16:33:55 pilight_ctrl myPilight rcv_raw: {"message":{"id":27,"unit":1,"state":"up"},"origin":"receiver","protocol":"arctech_screen_old","uuid":"0000-b8-27-eb-88e491","repeats":1}
2017-05-15 16:33:55 pilight_ctrl myPilight UNKNOWNCODE PISCREEN,arctech_screen_old,27,1,up
2017.05.15 16:33:55 3 : myPilight: Unknown code PISCREEN,arctech_screen_old,27,1,up, help me!
2017-05-15 16:33:55 pilight_ctrl myPilight rcv_raw: {"message":{"systemcode":14,"unitcode":18,"state":"on"},"origin":"receiver","protocol":"elro_800_switch","uuid":"0000-b8-27-eb-88e491","repeats":1}
2017-05-15 16:33:55 pilight_ctrl myPilight UNKNOWNCODE PISWITCH,elro_800_switch,14,18,on,14
2017.05.15 16:33:55 3 : myPilight: Unknown code PISWITCH,elro_800_switch,14,18,on,14, help me!2017-05-15 16:33:55 pilight_ctrl myPilight rcv_raw: {"message":{"id":27,"unit":1,"state":"on"},"origin":"receiver","protocol":"arctech_switch_old","uuid":"0000-b8-27-eb-88e491","repeats":1}
oder hier damit ich an die Daten von der Wetterstation komme:
2017.05.15 16:43:11 3: myPilight: Unknown code PITEMP,tfa,0,temperature:-67.77,humidity:0,battery:1, help me!
das könnte auch die LIDL-Wetterstation sein:
2017.05.15 16:33:55 3: myPilight: Unknown code PISWITCH,silvercrest,14,18,on,14, help me!
Zitat von: tklein am 15 Mai 2017, 16:49:07
habe hier hoffentlich mein Signal identifiziert:
Nee, glaube ich nicht ;)
Das "richtige" Protokoll für den Switch ist eher "arctech_switch_old"
Zitat von: tklein am 15 Mai 2017, 16:49:07
Was mache ich mit solchen Zeilen? @UNKNOWNCODE PISWITCH
Alles Andere mit 'ignoreProtocol' ignorieren.
Zitat von: HB86 am 10 Mai 2017, 11:24:33
Ich würde gerne den Status meiner Fensterkontakte aller 30min aktualisieren, allerdings funktioniert event-min-interval mit pilight-contact scheinbar nicht.
Hat jemand ähnliche Erfahrungen?
Meine Definition sieht so aus:
defmod Fenster_Bad pilight_contact GS-iwds07 60931
attr Fenster_Bad IODev PiLight
attr Fenster_Bad event-min-interval .*:1800
attr Fenster_Bad event-on-change-reading state
Jemand ne Idee? ???
Beißt sich das nicht mit event-on-change reading?
@Risiko,
mit dem anderen Protokoll klappt das auch nicht.
Internals:
CHANGED
DEF arctech_switch_old 30 10
ID 30
IODev myPilight
LASTInputDev myPilight
MSGCNT 25
NAME stripe_v2
NR 1069
PROTOCOL arctech_switch_old
STATE defined
SYSCODE
TYPE pilight_switch
UNIT 10
myPilight_MSGCNT 25
myPilight_TIME 2017-05-17 11:10:27
Readings:
Attributes:
IODev myPilight
room Pilight,Wohnzimmer
verbose 4 State: defined? Ist das normal? In den Logs sehe ich auch gar nicht, dass bei "set stripe_v2 on" etwas gesendet wird. Und ja ich habe das Protokoll aus dem ignore Protocol rausgenommen. :-)
ZitatWas mache ich mit solchen Zeilen? @UNKNOWNCODE PISWITCH
Alles Andere mit 'ignoreProtocol' ignorieren.
--> und wenn ich die Daten auswerten möchte?
Grüße
Thomas
Zitat von: HB86 am 10 Mai 2017, 11:24:33
Ich würde gerne den Status meiner Fensterkontakte aller 30min aktualisieren, allerdings funktioniert event-min-interval mit pilight-contact scheinbar nicht.
Hallo HB86,
verstehe leider nicht ganz, wie du das meinst. Der Status wird nur aktualisiert, wenn vom Kontakt auch ein Signal gesendet wird. Das macht er aber nur bei einem Zustandswechsel.
Zitat von: tklein am 17 Mai 2017, 11:30:11
@Risiko,
State: defined? Ist das normal? In den Logs sehe ich auch gar nicht, dass bei "set stripe_v2 on" etwas gesendet wird.
Setze mal das verbose vom pilight_ctrl (bei dir myPilight) auf 4.
Zitat von: tklein am 17 Mai 2017, 11:30:11
--> und wenn ich die Daten auswerten möchte?
Was willst du da auswerten? Entweder es gibt passende\zugehörige Geräte dafür, dann kannst du sie auch definieren oder es sind Falschmeldungen durch Rauschen, etc. Dann sollte man diese ignorieren.
Zitat von: Risiko am 18 Mai 2017, 22:42:55
Hallo HB86,
verstehe leider nicht ganz, wie du das meinst. Der Status wird nur aktualisiert, wenn vom Kontakt auch ein Signal gesendet wird. Das macht er aber nur bei einem Zustandswechsel.
Das ist mir schon klar. Ich will aber aller 30min ein Event erzeugen, damit meine Heizungssteuerung korrekt funktioniert und der Plot lückenlos ist.
Mit event-on-change-reading & event-min-interval sollte dies eigentlich funktionieren, bei meinen Homestatus-Dummy funktioniert das jedenfalls.
Zu event-on-change-reading siehe: https://forum.fhem.de/index.php?topic=26694.0
@ Risiko:
Verbose sollte schon auf 4 gewesen sein.
Zwischenzeitlich kann ich die Devices besser via meinem Signalduino verwalten. Daher werde ich mein Pilight bis auf weiteres deaktivieren.
Vielen Dank für die Hilfe!
Ich wünsche ein schönes Wochenende
Thomas
Zitat von: HB86 am 19 Mai 2017, 12:35:13
Das ist mir schon klar. Ich will aber aller 30min ein Event erzeugen, damit meine Heizungssteuerung korrekt funktioniert und der Plot lückenlos ist.
Mit event-on-change-reading & event-min-interval sollte dies eigentlich funktionieren, bei meinen Homestatus-Dummy funktioniert das jedenfalls.
Zu event-on-change-reading siehe: https://forum.fhem.de/index.php?topic=26694.0
Das glaube ich nicht.
event-min-interval löst von sich keinen Trigger aus. Es verhindert nur, dass bei sehr "gesprächigen" Geräten nicht ständig ein Trigger ausgelöst wird, sondern erst wieder nach einem Intervall.
http://fhem.de/commandref.html#event-min-interval
Außerdem sind das Standard-Readings von FHEM. Darum muss sich nicht jedes Modul selbst kümmern. Mach ich auch nicht.
Du kannst mit einem at und trigger aber selbst ein Trigger auslösen.
Zitat von: Risiko am 21 Mai 2017, 14:50:36
Das glaube ich nicht.
event-min-interval löst von sich keinen Trigger aus. Es verhindert nur, dass bei sehr "gesprächigen" Geräten nicht ständig ein Trigger ausgelöst wird, sondern erst wieder nach einem Intervall.
http://fhem.de/commandref.html#event-min-interval
Außerdem sind das Standard-Readings von FHEM. Darum muss sich nicht jedes Modul selbst kümmern. Mach ich auch nicht.
Du kannst mit einem at und trigger aber selbst ein Trigger auslösen.
Wie gesagt bei meinem Homestatus Dummy funktioniert das so. Wenn sich der Status ändert oder wenn 30min vergangen sind wird das Event getriggert.
Steht auch so in der Commandref:
ZitatFalls event-on-change-reading auch spezifiziert ist, dann werden sie mit ODER kombiniert, d.h. wenn einer der beiden Bedingungen wahr ist.
userReadings
D.h. wenn sich entweder das Reading ändert ODER event-min-intervall abgelaufen ist, wird getriggert.
Hi,
habe gerade einen neuen RPi mit FHEM/pilight aufgesetzt und fand gerade schade, dass es für pilight kein autocreate gibt. Im Thread gab es schon mal eine Diskussion dazu, wo entschieden wurde, dass autocreate aufgrund des tw. "Müll" was rein kommt sehr schlecht wäre.
Meine Idee für autocreate daher:
- Alles was GPIO ist automatisch anlegen (das hängt ja am RPi)
- Signale mit Repeat > 20 automatisch anlegen (erlaubt das "anlernen" per FB)
- Temperatursensoren/Kontakte anlegen wenn diese innerhalb von z.B. 5 Minuten 3x empfangen worden sind
Beim Löschen eines "autocreate" Devices müsste man dann noch automatisch im pilight_ctrl dieses Device "marken" damit es nicht wieder neu angelegt wird.
Was haltet ihr davon?
Gruß,
Dominik
Hallo,
sorry für die späte Meldung.
Die Ideen sind ja ok. Ich halte das aber persönlich für zuviel Arbeit für zu wenig Nutzen.
Hallo habe seid einiger zeit das Problem das ich keine Stechdosen mehr schalten kann und auch von meinem Temperatur Sensor keine Daten mehr kommen.
Wenn ich in pilight_ctrl auf disconnect und dann reset klicke geht es wieder komisch ist aber das der Status die ganze zeit connected steht.
Hat jemand ne Ahnung warum das so ist und was ich da machen kann?
Sorry betrifft nur das senden.
Im Log dazu das
2017.08.24 22:06:21 5: Funken(Write): Blocking Call running - will try it later
2017.08.24 22:06:22 5: Funken(SendNonBlocking): queue size 632
2017.08.24 22:06:22 5: Funken(Write): Blocking Call running - will try it later
Kein Support mehr?
Sorry. Ich kann das Problem nicht nachstellen. Starte doch mal neu, damit die Queue leer ist und stelle mal verbose von pilight_ctrl auf 4
Tritt das Problem mit dem Senden sofort oder erst im laufenden Betrieb auf?
Risiko
Okay mache ich, habe ich allerdings auch schon des öfteren gemacht also den pi neu gestartet.
Das Problem tritt erst nach einer Zeit X auf.
Ok. Wenn das Problem vorliegt, dann bitte mal versuchen mit Telnet und/oder pilight Web gui den pilight daemon zu erreichen.
Kann es daran liegen das ich pilight 7.0 installiert habe und in deinem pilight_ctrl API 6.0 steht?
Habe es mit 127.0.0.1:5005 7.0 definiert
Also Fehler wieder da!
Schalten aus fhem heraus nicht möglich,
pilight Web GUI erreichbar.
Schalten über Telnet mit pilight-send -p impuls -s 10 -u 16 funktioniert.
Ab hier ist der wurm drin
11:12:12 4: Funken(SendDone): message successfully send
2017.08.30 11:12:12 5: Funken(Parse): RCV -> {"origin":"sender","protocol":"impuls","message":{"systemcode":10,"programcode":16,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-f0779e"}
2017.08.30 11:12:12 5: Funken(Parse): protocol:impuls,id:10,unit:16
2017.08.30 11:12:12 4: Funken(Dispatch): PISWITCH,impuls,10,16,off,10
2017.08.30 11:12:12 5: Funken: dispatch PISWITCH,impuls,10,16,off,10
2017.08.30 11:12:12 4: pilight_switch_Parse: RCV -> PISWITCH,impuls,10,16,off,10
2017.08.30 11:12:13 5: Funken(SendNonBlocking): queue size 1
2017.08.30 11:12:13 5: Funken(Send): {"action":"send","code":{"protocol":["impuls"],"systemcode":10,"programcode":16,"off":1}}
2017.08.30 11:12:13 4: Funken(Send): RCV -> {"status":"success"}
2017.08.30 11:12:13 4: Funken(SendDone): message successfully send
2017.08.30 11:12:13 5: Funken(Parse): RCV -> {"origin":"sender","protocol":"impuls","message":{"systemcode":10,"programcode":16,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-f0779e"}
2017.08.30 11:12:13 5: Funken(Parse): protocol:impuls,id:10,unit:16
2017.08.30 11:12:13 4: Funken(Dispatch): PISWITCH,impuls,10,16,off,10
2017.08.30 11:12:13 5: Funken: dispatch PISWITCH,impuls,10,16,off,10
2017.08.30 11:12:13 4: pilight_switch_Parse: RCV -> PISWITCH,impuls,10,16,off,10
2017.08.30 11:12:14 5: Funken(Parse): RCV -> {"message":{"systemcode":29,"unitcode":29,"state":"on"},"origin":"receiver","protocol":"elro_800_switch","uuid":"0000-b8-27-eb-f0779e","repeats":1}
2017.08.30 11:12:14 5: Funken(Parse): protocol:elro_800_switch,id:29,unit:29
2017.08.30 11:12:14 4: Funken(Dispatch): PISWITCH,elro_800_switch,29,29,on,29
2017.08.30 11:12:14 5: Funken: dispatch PISWITCH,elro_800_switch,29,29,on,29
2017.08.30 11:12:14 4: pilight_switch_Parse: RCV -> PISWITCH,elro_800_switch,29,29,on,29
2017.08.30 11:12:14 3: Funken: Unknown code PISWITCH,elro_800_switch,29,29,on,29, help me!
2017.08.30 11:12:14 5: Funken(Parse): RCV -> {"message":{"systemcode":29,"unitcode":29,"state":"on"},"origin":"receiver","protocol":"silvercrest","uuid":"0000-b8-27-eb-f0779e","repeats":1}
2017.08.30 11:12:14 5: Funken(Parse): protocol:silvercrest,id:29,unit:29
2017.08.30 11:12:14 4: Funken(Dispatch): PISWITCH,silvercrest,29,29,on,29
2017.08.30 11:12:14 5: Funken: dispatch PISWITCH,silvercrest,29,29,on,29
2017.08.30 11:12:14 4: pilight_switch_Parse: RCV -> PISWITCH,silvercrest,29,29,on,29
2017.08.30 11:12:14 3: Funken: Unknown code PISWITCH,silvercrest,29,29,on,29, help me!
2017.08.30 11:12:14 5: Funken(Parse): RCV -> {"message":{"id":4,"unit":2,"state":"up"},"origin":"receiver","protocol":"arctech_screen_old","uuid":"0000-b8-27-eb-f0779e","repeats":1}
2017.08.30 11:12:14 5: Funken(Parse): protocol:arctech_screen_old,id:4,unit:2
Wenn du das ganze logfile brauchst kann ich es dir gerne zusenden.
Hoffe die Infos helfen weiter
Nabend Tueftler1983,
leider kann ich aus dem Logauszug nichts erkennen. Das Senden war immer erfolgreich.
Es kommen aber auch noch andere Protokolle rein, evtl. Rauschen?
Bitte mal das komplette Log anhängen.
Hinweis:
1. pilight-send meine ich nicht. Meine telnet 127.0.0.1 5005 (du hast in der config.json Port 5005 stehen!?)
2. Bei der API gibt es nur die Unterscheidung 5.0 oder >5.0 also 6. Zwischen pilight Version 6 und 7 wurde die API nicht geändert.
Risiko
Habe das Logfile als zip angehängt da es sonnst 21 MB groß ist
Auch mit telnet kann ich mich verbinden wenn aus fhem heraus nix mehr geht.
Hallo Tueftler1983,
kann leider noch nichts genaues identifizieren. Ich habe heute pilight und fhem geupdatet und kann den Fehler leider nicht nachstellen.
Mir ist im Log nur aufgefallen, dass der pilight daemon zugespammt wird. Mehrfach pro Sekunde wird versucht was an den daemon zu senden. Das kann irgendwie nicht alles so schnell verarbeitet werden und die Sendequeue läuft voll.
Die Sendequeue kann nicht geleert werden, da immer wieder neuer Sendbefehle rein kommen, welche nicht abgearbeitet werden.
Also mal die Frage, warum wird da soviel pro Sekunde gesendet?
Risiko.
Hmm gute frage mehrfach pro Sekunde sollte eigentlich nichts gesendet werden habe nichts was so schnell schalten soll oder kann.
Hmm woher kommt das nur...
Hi, ich wollte gestern endlich mal von Pilight auf FHEM wechseln, zuerst mal pilight_crtl definiert und dann meine 2 d18b20 definiert, soweit so gut
Dann wollte ich meine Funksteckdosen definieren (B1 Dosen ausm Toom Baumarkt) welche in Pilight wiefolgt geschaltet werden:
"Lampe1": {
"protocol": [ "heitech" ],
"id": [{
"systemcode": 21,
"unitcode": 1
}],
"state": "off"
},
Also hab ich "define Deckenlampe pilight_switch heitech 1 21" eingegeben, es passierte garnichts :(
Ich hab dann mal etwas im Thread gestöbert und bin auf die Idee gekommen in die 10_pilight_crtl.pm an 2 stellen:
case m/heitech/ {$code .= "\"systemcode\":$syscode,\"unitcode\":$unit,";}
einzufügen und konnte so wenn ich die Dose mit "define Deckenlampe pilight_switch heitech 0 1 21" definiert habe zumindest schon mal die Dose Schalten, aber nur über die einzelnen ON OFF Buttons, davor bleibt weiterhin defined stehen und ich kann die Dosen auch nicht über eine App Schalten :(
Kann mir da jemand helfen bzw sagen was ich falsch mache? Oder evtl der Ersteller des Moduls die Dosen richtig hinzufügen ;) , ich Bau dir eher nen Kopter (Drohne) oder so :D
Mich nervt das pilight Interface und ich hab keine Lust neue Dosen zu holen ;)
Hallo,
Hast du fhem dann auch neu gestartet oder zumindest das Modul neu geladen??
Wenn ja versuche es mal mit der angehängten pilight_ctrl
Ich habe mir gestern auch erfolgreich meine billig Fensterkontakte eingebunden und jetzt dein Protokoll.
Versuche es einfach mal und dann den Neustart von fhem nicht vergessen.
Ich habe das Protokoll "heitech" aufgenommen und eingecheckt
Grade mal versucht, mit der Version kann ich die Dosen wenigstens normal mit "define Deckenlampe pilight_switch heitech 21 1" definieren, also ohne die 0 dazwischen wie bei mir!
Aber am Rest hat sich nichts geändert, davor bleibt immernoch defined stehen, da sollte doch eine Glühbirne erscheinen oder?
Im Moment kann ich wenn ich da drauf klicke (also auf den "defined" Text) nur An Schalten, wieder aus muss ich dann über den off Button daneben!
Dann arctech_screen_old bitte auch aufnehmen , ist ein Fenster Kontakt habe ihn unter pilight_contact eingebettet.
Zitat von: KampfGurke am 03 September 2017, 20:08:17
Grade mal versucht, mit der Version kann ich die Dosen wenigstens normal mit "define Deckenlampe pilight_switch heitech....
Bitte mal Logs anhängen! So kann ich nicht helfen.
Zitat von: Tueftler1983 am 03 September 2017, 20:10:50
Dann arctech_screen_old bitte auch aufnehmen , ist ein Fenster Kontakt habe ihn unter pilight_contact eingebettet.
Das ist kein switch Protokoll! Das ist arctech_switch_old und das gibt es schon!
Bei mir taucht es im eventMonitor aber als arctech_screen_old auf wenn ich den Fensterkontakt auslÖse und sendet mir ein up.
Gibt nur das eine Signal ( up)
Deshalb habe ich es unter CONTACT eingetragen.
vorher konnte ich es zwar definieren aber der state blieb auf defined
Hatte "Briefpasten pilight_switch arctech_screen_old 22 13"
Und "Briefpasten pilight_contact arctech_screen_old 22 13"
Versucht beides ohne erfolg!
Log´s? Gerne doch :)
Also das zeigt mir FHEM wenn ich einmal off und wieder on Schalte:
2017.09.04 20:24:22 4 : pilight(Write): RCV (pilight_switch) -> Deckenlampe,off
2017.09.04 20:24:22 4 : pilight(Write): {"action":"send","code":{"protocol":["heitech"],"systemcode":21,"unitcode":1,"off":1}}
2017.09.04 20:24:22 5 : pilight(SendNonBlocking): queue size 1
2017.09.04 20:24:22 4 : pilight(SendDone): message successfully send
2017.09.04 20:24:23 5 : pilight(Parse): RCV -> {"origin":"sender","protocol":"heitech","message":{"systemcode":21,"unitcode":1,"state":"off"},"repeat":1,"uuid":"0000-02-cc-05-c1cfc7"}
2017.09.04 20:24:23 5 : pilight(Parse): protocol:heitech,id:21,unit:1
2017-09-04 20:24:23 pilight_ctrl pilight rcv_raw: {"origin":"sender","protocol":"heitech","message":{"systemcode":21,"unitcode":1,"state":"off"},"repeat":1,"uuid":"0000-02-cc-05-c1cfc7"}
2017.09.04 20:24:23 3 : pilight(Parse): unknown protocol -> heitech
2017.09.04 20:24:23 4 : pilight(Write): RCV (pilight_switch) -> Deckenlampe,on
2017.09.04 20:24:23 4 : pilight(Write): {"action":"send","code":{"protocol":["heitech"],"systemcode":21,"unitcode":1,"on":1}}
2017.09.04 20:24:23 5 : pilight(SendNonBlocking): queue size 1
2017.09.04 20:24:23 4 : pilight(SendDone): message successfully send
2017.09.04 20:24:24 5 : pilight(Parse): RCV -> {"origin":"sender","protocol":"heitech","message":{"systemcode":21,"unitcode":1,"state":"on"},"repeat":1,"uuid":"0000-02-cc-05-c1cfc7"}
2017.09.04 20:24:24 5 : pilight(Parse): protocol:heitech,id:21,unit:1
2017-09-04 20:24:24 pilight_ctrl pilight rcv_raw: {"origin":"sender","protocol":"heitech","message":{"systemcode":21,"unitcode":1,"state":"on"},"repeat":1,"uuid":"0000-02-cc-05-c1cfc7"}
2017.09.04 20:24:24 3 : pilight(Parse): unknown protocol -> heitech
Hat sich erledigt, hab weiter unten noch die passende Zeile eingefügt:
switch($proto){
#switch
case m/switch/ {$protoID = 1;}
case m/elro/ {$protoID = 1;}
case m/silvercrest/ {$protoID = 1;}
case m/mumbi/ {$protoID = 1;}
case m/brennenstuhl/{$protoID = 1;}
case m/heitech/ {$protoID = 1;} <<<<---
case m/pollin/ {$protoID = 1;}
Dann geht es!
Also hab ich beim ersten mal nur den Fehler gemacht das ich oben $id durch $syscode ersetzt hab ;)
Hab das funktionierende File angehängt!
Zitat von: KampfGurke am 04 September 2017, 21:50:51
Hat sich erledigt, hab weiter unten noch die passende Zeile eingefügt:
Hab das funktionierende File angehängt!
Das hatte ich gestern schon so eingecheckt. Also sollte es per Update heute verfügbar sein!
Zitat von: Tueftler1983 am 04 September 2017, 20:02:17
Bei mir taucht es im eventMonitor aber als arctech_screen_old auf wenn ich den Fensterkontakt auslÖse und sendet mir ein up.
Siehe hier https://wiki.pilight.org/doku.php/protocols
Ich weiß leider selbst nicht so richtig, was 'Screens' sein sollen. Nehme mal an, wenn man was "gedrückt hält"
Hallo zusammen,
ich nutze "schon seit Jahren" Pilight zum schalten diverser Steckdosen und Schalter. Diese habe ich über das entsprechende Modul auch an FHEM angebunden.
Schalten funktioniert auch wie gewünscht. Allerdings updatet sich der Status nicht - was er in der Pilight GUI direkt tut.
Ich habe z.b. ein paar Lampen die eingeschaltet werden und nach 90min automatisch in Pilight wieder ausgeschaltet werden. Funktioniert auch super, aber diese Statusänderung kommt eben nicht in FHEM an. Habe ich eine Fehlkonfiguration gemacht, oder gibt es das Modul einfach nicht her? Die Readings stehen immer auf "off".
Beste Grüße
Jan
Normalerweise wenn du pilight_ctrl, pilight_switch und co nutzt brauchst du keine devices in pilight konfigurieren. Du definierst sie komplett in fhem und dann solltest du alle status Änderungen auch fhem sehen, auch wenn du mit der Fernbedienung schaltest.
Zitat von: stratege-0815 am 05 September 2017, 16:26:45
Ich habe z.b. ein paar Lampen die eingeschaltet werden und nach 90min automatisch in Pilight wieder ausgeschaltet werden.
Hallo. Wer schaltet die Lampen wieder aus FHEM oder pilight? Wenn es pilight macht (wusste gar nicht, dass das geht) dann wird dies womöglich über die Schnittstelle nicht mitgeteilt!
Wenn du in FHEM an und aus schaltest, sollte sich der Zustand in FHEM auch ändern. Wenn du die gleichen Geräte (Protokoll und ID's) auch in pilight definiert hast, dann sollte sich der Zustand auch in pilight webgui ändern. Es geht sogar, wenn du in pilight webgui schaltest, bekommt das auch FHEM mit. Gerade nochmal getestet.
ZitatWenn du die gleichen Geräte (Protokoll und ID's) auch in pilight definiert hast, dann sollte sich der Zustand auch in pilight webgui ändern.
Bei mir ist es zumindest so!
ZitatWenn es pilight macht (wusste gar nicht, dass das geht)
Pilight kann das seit 6.0!
https://manual.pilight.org/de/eventing (https://manual.pilight.org/de/eventing)
Bis ich gelernt hab wie ich Fhem sage es soll bei Sonnenunter/aufgang Lampen Schalten ist das auch gut so ;)
Für fhem schalten bei Sonnen auf und untergang:
Sunset und sunrise in einem DOIF das dann dein device schaltet
Danke, Super quasi genauso wie bei Pilight :)
Zeiten muss ich nicht mehr setzen bzw Zeitzonen oder?
Dafür wollte Pilight GPS Koordinaten!
"Sonne": {
"protocol": [ "sunriseset" ],
"id": [{
"longitude": 7.5343021,
"latitude": 50.6636419
}],
"sunrise": 7.13,
"sunset": 18.14,
"sun": "rise"
},
Hat aber Zeit, ich bin grade eh am TabletUi basteln, solange kann Pilight das tun ;)
Ahja die Werte:
"sunrise": 7.13,
"sunset": 18.14,
"sun": "rise"
werden von Pilight aktualisiert, deshalb passen die Zeiten auch nicht das File war von der Letzten änderung an Pilight im März/April ;)
Doch du muß deine GPS Position in fhem unter Global eingeben damit die richtigen werten gearbeitet wird, zusätzlich hast du die Möglichkeit bei Sunset und sunrise noch Offset festzulegen falls du z.b. Lieber eine Stunde vor oder nach Sunset oder sunrise schalten willst
Danke, hab auch endlich den Gefällt mir Button gefunden :D
Etwas unübersichtlich hier ;)
Zitat von: Tueftler1983 am 05 September 2017, 18:21:14
Normalerweise wenn du pilight_ctrl, pilight_switch und co nutzt brauchst du keine devices in pilight konfigurieren. Du definierst sie komplett in fhem und dann solltest du alle status Änderungen auch fhem sehen, auch wenn du mit der Fernbedienung schaltest.
Okay, ich habe nochmal eben gecheckt, ich habe damals das einfach Modul "pilight" verwendet. Die Schalter sind so eingerichtet:
define Regalbeleuchtung pilight brennenstuhl
attr Regalbeleuchtung room Homekit,Esszimmer
attr Regalbeleuchtung systemcode 31
attr Regalbeleuchtung unitcode 2
Das heisst ich muss die erst einmal alle "umbauen"....
Ja die Definition lautet dann
define Regalbeleuchtung pilight_switch brennstuhl 31 2
Aber nicht vergessen vorher das pilight_ctrl zu definieren, das ist die Schnittstelle zwischen pilight und FHEM für diese module
Guten Tag,
ich habe jetzt exemplarisch ein "altes" Pilight Device gelöscht und es wie oben beschrieben neu angelegt.
Das war auch teilweise erfolgreich. Ich habe es wieder den Räumen Esszimmer und Homekit zugeordnet. In FHEM erscheint es komischerweise aber nicht in den Räumen Esszimmer oder Homekit. Das schalten funktioniert, auch in der Apple Home Anwendung. Aber als "state" erhalte ich nur ein "defined" - ich hätte erwartet das hier jetzt ein "on" oder "off" erscheint, was ja mein ursprüngliches Problem war. Das mein Schalter nicht in den Räumen erscheint macht es etwas unübersichtlicher, da ich ihn nun nur noch im Bereich "unsorted" finden kann.
Kann jemand hier aufklären was noch falsch läuft?
Gruß
Jan
Ein list vom Device und ein log Auszug mit verbose 5 in pilight_ctrl würde helfen.
Naja, ein
attr Pilight_Device room Esszimmer,Homekit
Sollte schon reichen, oder?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hallo,
ich arbeite schon einige Zeit mit FHEM und Pilight.
Nun bin ich auf dieses Modul gestossen und wollte es anstelle von 98_pilight verwenden, da es die on-for-timer Methode unterstützen soll.
Leider bekomme ich keinen Connect zur Pilight API.
Ich bekomme immer wieder :Could not connect to pilight-daemon
Auch ein :
Can't open <192.168.0.200:5000>: No such file or directory bekomme ich im Log.
Die IP ist richtig (localhost habe ich auch schon probiert). Port 5000 lauscht (Funktioniert ja auch mit 98_pilight)
Ein tcpdump -i eth0 port 5000 bleibt auch stumm, obwohl er ja wenigstens versuchen müsste zu connecten.
Fehlt mir da irgendein Perl-Modul??
LG,
Ingo
Hast du denn pilight_ctrl definiert?
Hi,
ja, sonst würde die Meldung nicht kommen:
define pilightZWEI pilight_ctrl <192.168.0.200:5000>
Nimm mal < und > aus der definition
define pilightZWEI pilight_ctrl 192.168.0.200:5000 7.0
Versuch es mal so
Achso und Port 5000 ist auch in der pilight config eingetragen denke ich also die Zeile
port "5000"
Zitat von: eisi am 14 September 2017, 19:13:32
Hallo,
ich arbeite schon einige Zeit mit FHEM und Pilight.
Nun bin ich auf dieses Modul gestossen und wollte es anstelle von 98_pilight verwenden, da es die on-for-timer Methode unterstützen soll.
Leider bekomme ich keinen Connect zur Pilight API.
Ich bekomme immer wieder :Could not connect to pilight-daemon
Auch ein :
Can't open <192.168.0.200:5000>: No such file or directory bekomme ich im Log.
Die IP ist richtig (localhost habe ich auch schon probiert). Port 5000 lauscht (Funktioniert ja auch mit 98_pilight)
Ein tcpdump -i eth0 port 5000 bleibt auch stumm, obwohl er ja wenigstens versuchen müsste zu connecten.
Fehlt mir da irgendein Perl-Modul??
LG,
Ingo
Hast du auf Strech upgedatet?
Ich habe seit dem Update das problem, dass mir ps -ef keinen daemon mehr anzeigt, mit systemctrl status wird mir abe angezeigt, dass alles funktioniert und fhem ist natürlich verständlicherweise auf disconnected API wird bei mir auch 6 angezeigt obwohl bei ich bei DEF <ip>:<port> 7 eingetragen habe
Das mit der API ist okay,
Pilight 6 und 7 verwenden die API 6
Hallo eisi,
verwendest du evtl. noch das 98_pilight zusammen mit pilight_ctrl und beide wollen sich auf port 5000 verbinden!?
Den Port hast du ja hoffentlich bei pilight in der Config eingestellt! Du verwendest auf pilight 7?
Sonst mal verbose von pilight_ctrl auf 5 stellen und schauen was im Log so an kommt.
Hi,
die Antwort von Tueftler1983 war die Richtige :-)
<IP> war falsch. IP wäre richtig.
Könnte man das mal in der Doku ändern?
Pilight kann auf mehreren Connections hören.
Aber Danke für die Antworten. Edlich habe ich das gefunden, was ich suchte.
Ich habe mir das 98_Pilight 2 mal geklont und abgeändert. Dank des IODev brauche ich das ja jetzt nicht mehr.
Ich arbeite mit 3 Pilights im ganzen Haus.
Danke an Risiko für die Programmierarbeit!!!
LG,
Ingo
Freut mich das es jetzt läuft
👍
Jup :-)
Jetzt wird die ganze Config umgeschrieben.
define pilight_oben pilight_ctrl 192.168.0.200:5000
define pilight_unten pilight_ctrl 192.168.0.201:5000
define pilight_garten pilight_ctrl 192.168.0.203:5000
Das wird ein Spaß :-)
Hehe
Hallo zusammen,
eventuell habe ich das hier (im langen Thread) überlesen...kann man eigentlich am RaspberryPi mehrere Sensoren mit dem selben Protokoll einbinden, die am selben GPIO Port empfangen werden?
Laut der Beschreibung:
pilight_temp: - Repräsentation eines Temperatur- und Luftfeuchtigkeitssensors bzw. Wetterstation
define <name> pilight_temp <protocol> <id>
Bei GPIO Sensoren muss als id der GPIO-Pin angegeben werden.
Wenn ich z.B. mehrere Sensoren mit dem Protokoll "oregon_21" verwende, kann ich zwar in Pilight direkt die "device_id" und die "id" (den Kanal) einstellen, aber in Fhem würden trotzdem alle diese Sensoren im selben Device landen?
Danke für Erklärung
Lars
Zitat von: Lars721 am 01 Oktober 2017, 09:42:52
Bei GPIO Sensoren muss als id der GPIO-Pin angegeben werden.
Ich bin mir nicht sicher, ob die ID immer die Pinnummer ist. Hängt sicherlich vom Protokoll ab.
Siehe https://manual.pilight.org/protocols/gpio/index.html
Bei "oregon_21" ist die ID die ID des Sensors! Leider ist es in der offiziellen Doku nicht gelistet.
https://manual.pilight.org/protocols/433.92/weather/index.html
Ich weiß nicht, ob es schon die die offizielle pilight Version geflossen ist.
Hallo Risiko,
danke für die Antwort.
Einen Oregon Sensor (THGR228N) habe ich bereits über Pilight an Fhem angebunden.
Die device_id laut Pilight ist 7456
Die id ist 1 (die Kanal ID)
Hier in Fhem musste ich als ID eine 1 angeben.
(Der 433 MHz Empfänger ist an meinem Raspi an GPIO1 (wiringPi Bezeichnung) angeschlossen).
Ich wollte jetzt nur wissen, ob man dann einen zweiten Sensor gleichzeitig betreiben kann, weil der dann ja auch über GPIO1 "angeschlossen" ist...
Das Oregon_21 Protokoll ist noch nicht in der offiziellen Pilight Version 7 eingeflossen.
Ich habe die Version aus dem Pilight test-dev Verzeichnis genommen.
Zitat von: Lars721 am 03 Oktober 2017, 13:53:08
Die device_id laut Pilight ist 7456
Die id ist 1 (die Kanal ID)
Das verstehe ich leider nicht. Was sagt den pilight_receive bzw. das Log, wenn die verbose von pilight_ctrl auf 4 stellst?
Die device_id 7456 kommt von pilight_receive
Als rcv_raw von pilight_ctrl erhalte ich:
{"message":{"device_id":7456,"id":1,"unit":111,"battery":1,"temperature":19.20,"humidity":45.0},"origin":"receiver","protocol":"oregon_21","uuid":"0000-b8-27-eb-c21f9a","repeats":2}
Hallo,
ich habe jetzt mal folgendes getestet:
Am Sensor kann man den Kanal einstellen von 1-3
Ich habe jetzt von Kanal 1 auf Kanal 3 umgestellt.
Jetzt erhalte ich bei rcv_raw von pilight_ctrl:
{"message":{"device_id":7456,"id":3,"unit":113,"battery":1,"temperature":21.50,"humidity":43.0},"origin":"receiver","protocol":"oregon_21","uuid":"0000-b8-27-eb-c21f9a","repeats":2}
In meinem Fhem Device muss ich nun folgendes einstellen, damit ich wieder Daten erhalte:
defmod Oregon_Sensor pilight_temp oregon_21 3
Anscheinend bezieht sich die ID im Fhem Pilight Modul auf die (Kanal-)id von Pilight und nicht auf die device_id von Pilight
Dann habe ich es jetzt auch endlich verstanden.
Man kann verschiedene Oregon Sensoren einbinden mit verschiedenen Kanal-ID's.
Theoretisch könnte man aber auch bei der Definition von pilight_Temp
define <name> pilight_temp <protocol> <id>
die device_id mit als zusätzlichen Parameter anfügen.
Dann könnte man in Fhem noch mehrere Oregon_21 Sensoren einbinden
@Risiko: wäre das sinnvoll/machbar?
Danke schon mal
Gruß,
Lars
Das oregon_21 Protokoll verhält sich hier meiner Meinung nach anders. Es gibt hier zur "id" noch eine "device_id". Das gibt es bei anderen Protokollen nicht!! (z.B. https://manual.pilight.org/protocols/gpio/lm76.html oder https://manual.pilight.org/protocols/433.92/weather/alecto_wsd17.html)
Wenn es unbedingt erforderlich ist, könnte ich die Ausnahme umsetzen und bei diesem Protokoll "device_id" statt "id" verwenden. Da es aber auch noch nicht in die offizielle pilight Version geflossen ist, würde ich damit erstmal warten. Evtl. tut sich da ja noch was, vor allem weil sich unit auch ändert. Meiner Meinung nach müsste ID=7456 und unit=1 oder 3 sein! Oder noch besser, es müsste sich an das tfa (https://manual.pilight.org/protocols/433.92/weather/tfa.html) Protokoll anlehnen. Dann könnte man pilight_temp id channel machen. Hat bis jetzt wohl noch niemand gebraucht.
Hallo,
ich habe da mal gerne ein Problem :-)
Ich bauen gerade alles von dem 98_pilight auf das pilight_switch Modul um.
Es reagiert etwas komisch bei ein paar Schaltern:
FHEM:
define Grillbeleuchtung pilight_switch kaku_switch 4019034 14
attr Grillbeleuchtung IODev pilight_garten
attr Grillbeleuchtung alias Grillbeleuchtung
attr Grillbeleuchtung devStateIcon on:general_an@red off:general_aus@grey
attr Grillbeleuchtung group Schalter
attr Grillbeleuchtung icon light_ceiling
attr Grillbeleuchtung room Aussen
define Ofenbeleuchtung pilight_switch kaku_switch 4019034 15
attr Ofenbeleuchtung IODev pilight_garten
attr Ofenbeleuchtung alias Ofenbeleuchtung
attr Ofenbeleuchtung devStateIcon on:general_an@red off:general_aus@grey
attr Ofenbeleuchtung group Schalter
attr Ofenbeleuchtung icon light_ceiling
attr Ofenbeleuchtung room Aussen
Events:
2017-10-27 18:43:10 pilight_ctrl pilight_garten rcv_raw: {"origin":"sender","protocol":"arctech_switch","message":{"id":4019034,"unit":14,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-7d1439"}
2017-10-27 18:43:10 pilight_ctrl pilight_garten UNKNOWNCODE PISWITCH,arctech_switch,4019034,14,off
2017-10-27 18:44:15 pilight_ctrl pilight_garten rcv_raw: {"origin":"sender","protocol":"arctech_switch","message":{"id":4019034,"unit":15,"state":"on"},"repeat":1,"uuid":"0000-b8-27-eb-7d1439"}
Warum geht der eine Schalter, der andere Schalter nicht?
Hallo.
Meiner Meinung sollte so keiner gehen ;), wenn du in pilight_ctrl nicht das Attribut 'brands' verwendest.
Grund: "kaku_switch" ist ein anderer Name (brand) für "arctech_switch". Am Besten du definierst all diese Schalter mit dem "arctech_switch" Protokoll oder du musst in pilight_ctrl
brands: kaku_switch:arctech_switch setzen
Risiko
Naja, einer ging :-)
Hab das jetzt mal so codiert und ein neues Wunder tut sich auf :-)
Mit der FHEM-App auf Android, kann ich sie nicht schalten :-(
Mit dem FTUI auf dem Pad geht es problemlos.
In FHEM selber wird nur der Zustand "defined" angezeigt.
Was steht denn im Log? Ggf. mal verbose von pilight_ctrl auf 4 setzen.
2017.11.05 12:50:16 4: pilight_unten(Write): RCV (pilight_switch) -> Grillbeleuchtung,on
2017.11.05 12:50:16 4: pilight_unten(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":4019034,"unit":14,"on":1}}
2017.11.05 12:50:16 4: pilight_unten(Send): RCV -> {"status":"success"}
2017.11.05 12:50:16 4: pilight_unten(SendDone): message successfully send
2017.11.05 12:50:17 4: pilight_unten(Dispatch): PISWITCH,arctech_switch,4019034,14,on
2017.11.05 12:50:17 4: pilight_switch_Parse: RCV -> PISWITCH,arctech_switch,4019034,14,on
Sehe da leider keinen Fehler.
Heist du vielleicht eine oder mehrere pilight_ctrl definiert? Du brauchst nu eins.
Seige doch mal die defines von pilight_ctrl und pilight switch. Bitte auch noch das verbose von pilight_switch auf 4 stellen.
Du sendest immer noch mit "kaku_switch" protocol. Kommt sowas wie Unknown Code? Sende doch mit "arctec_switch"
define pilight_oben pilight_ctrl 192.168.0.200:5000
attr pilight_oben brands kaku_switch:arctech_switch
define pilight_unten pilight_ctrl 192.168.0.201:5000
attr pilight_unten brands kaku_switch:arctech_switch
attr pilight_unten verbose 4
#define pilight_garten pilight_ctrl 192.168.0.204:5000
#attr pilight_garten brands kaku_switch:arctech_switch
#attr pilight_garten verbose 4
Ja, ich habe mehrere Ctrls, da ich auch 3 RaspberryPis mit Pilght über das Grundstück, bzw im Haus verteilt habe.
Ich habe aber nochwas festgestellt, daher ist pilight_garten auskommentiert.
Ich habe mit der 98_pilight.pm gearbeitet. Die habe ich mir umprogrammiert, sodass 3 Stück davon laufen.
Das ging auch alles, bis ich in FTUI die Funktion set on for timer gefunden habe :-)
Da musste dann pilight_switch her.
Bei mehreren pilight_ctrl musst du jedem switch mittels 'IODev' das "richtige" Control zuweisen!
Alternativ kannst du dich auch mit pilight Ad-Hoc Netzwerk beschäftigen.
https://manual.pilight.org/adhoc_network.html
Dann brauchst du in fhem nur ein pilight_ctrl.
Das IODev ist immer gesetzt.
Das mit dem Netzwerk hatte ich schon. Das funktioniert einmal fast und einmal garnicht :-)
Zitat von: eisi am 07 November 2017, 21:01:04
Das IODev ist immer gesetzt.
Auch das Richtige?
Leider bin ich mit meinen Ideen dann auch am Ende. Konnte keinen Fehler erkennen
Wie kann ich denn direkt die Aktoren im Pilight Network ansprechen?
Per Name?
Wenn ich mir jetzt die Arbeit mache über 20 Aktoren da reinzubasteln, wäre es gut zu wissen, was ich in FHEM ändern muss :-)
Verstehe leider die Frage nicht!!!!!!!!
Nein, schon gut.
Sorry, Denkfehler :-)
Hallo,
ich versuche gerade das Modul zum laufen zu bringen und komme nicht weiter.
Folgenden Befehl verwende ich:
define myPilightCtrl pilight_ctrl 192.168.178.33:5001 8.0
Mein fhem Frontend stürzt daraufhin ab. Folgenden Fehler bekomme ich im logfile:
2017.12.03 23:07:43 3: myPilightCtrl device opened malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "HTTP/1.0 404 Not Fou...") at ./FHEM/10_pilight_ctrl.pm line 735.
Danach bekomme ich im Browser nur ein "unable to connect". Liegt das an pilight 8.0.4?
Ich weiß nicht, ob die 8.0 schon unterstützt wird.
Bei meinen 4 Raspis wollte die nicht laufen und war irgendwie nicht abwärtskompatibel.
Ich würde die Version 7 installieren und die Api-Version weglassen.
Läuft bei mir einwandfrei.
Wenn du die 7 installieren willst, musst du dir beide Pakete (pilight und Webgui) von der Seite runterladen
und mit dpkg -i gleichzeitig installieren.
Gruß,
Ingo
Hallo nochmals,
ich benutze jetzt Version 7.0 wie eisi vorgeschlagen hat und jetzt stürzt das define auch nicht mehr ab. Ich habe aber wie Lars721 den test_dev branch vom wo-rasp fork von Pilight selber kompiliert, damit ich das oregon2.1 Protokoll nutzen kann. Ich empfange auch schon Temperaturen in der webgui über 192.168.178.33:5001
Leider klappt das connecten von pilight_ctrl mit folgendem Befehl nicht:
define myPilightCtrl pilight_ctrl 192.168.178.33:5001
Bei Debuglevel 5 kommen folgende Meldungen vor:
2017.12.05 01:18:14 4: myPilightCtrl(Check): Could not connect to pilight-daemon 192.168.178.33:5001 - maybe wrong api version or port
2017.12.05 01:18:14 1: 192.168.178.33:5001 disconnected, waiting to reappear (myPilightCtrl)
2017.12.05 01:19:15 5: myPilightCtrl(TryConnect): disconnected
Woran könnte das liegen? Ich habe die IP-Adresse nicht mit <> umklammert.
Hallo,
5001 ist der Port des Webinterfaces.
Du musst, für die Api, den Port 5000 nehmen.
define myPilightCtrl pilight_ctrl 192.168.178.33:5000
Settings port:5000 in der config.json nicht vergessen!
Danke eisi und Risiko, jetzt läuft es prima! :)
Ich muss noch einen Empfänger finden, der eine größere Reichweite hat, bis draußen reicht es noch nicht ::)
Eine kleine Antenne würde reichen.
Das Modul , was bei Pilight beschrieben ist, tut auch seinen Dienst.
Es kommt immer darauf an, was du empfangen willst.
LG,
Ingo
Hallo,
habe Problrme mit laden von pilight_ctrl. Pilight Version ist 8.0.4, läuft und kann ist auch über Web-Gui erreichbar.
Zitat2017.12.09 15:25:53 5: Cmd: >define EasyFunk pilight_ctrl Localhost:5000 [6.0]<
2017.12.09 15:25:53 5: Loading ./FHEM/10_pilight_ctrl.pm
2017.12.09 15:25:53 1: reload: Error:Modul 10_pilight_ctrl deactivated:
Can't locate Switch.pm in @INC (you may need to install the Switch module) (@INC contains: . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/arm-linux-gnueabihf/perl5/5.24 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base ./FHEM) at ./FHEM/10_pilight_ctrl.pm line 61, <$fh> line 72.
BEGIN failed--compilation aborted at ./FHEM/10_pilight_ctrl.pm line 61, <$fh> line 72.
2017.12.09 15:25:53 0: Can't locate Switch.pm in @INC (you may need to install the Switch module) (@INC contains: . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/arm-linux-gnueabihf/perl5/5.24 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base ./FHEM) at ./FHEM/10_pilight_ctrl.pm line 61, <$fh> line 72.
BEGIN failed--compilation aborted at ./FHEM/10_pilight_ctrl.pm line 61, <$fh> line 72.
2017.12.09 15:25:53 5: Cmd: >attr EasyFunk room Haus<
2017.12.09 15:25:53 5: Cmd: >attr EasyFunk verbose 5<
welches Modul fehlt hier?
LG Uwe
Zitat von: SimpfUwe am 09 Dezember 2017, 16:45:48
Hallo,
habe Problrme mit laden von pilight_ctrl. Pilight Version ist 8.0.4, läuft und kann ist auch über Web-Gui erreichbar.
welches Modul fehlt hier?
LG Uwe
Versuch mal das "sudo apt-get install libswitch-perl" ;)
Das wars - herzlichen Dank!
LG Uwe
Hi,
Can't locate Switch.pm
Das ist ein Perlmodul, was du noch installieren musst.
sudo apt-get install libswitch-perl
Hallo in die Runde,
ich habe folgendes Problem mit dem Modul, dass ich jetzt mal versuche zu beschreiben.
Ich setzte pilight V7 in Zusammenhang mit der Firmware für den nano ein.
Wenn ich nun den raspberry per reboot oder shutdown "stromlos" mache, so funktioniert pilight im Anschluss nicht mehr.
Folgende Logeinträge sind dann zu sehen (nach betätigen des "Schalters" im Frontend):
z.B. ausschalten
2018.01.02 17:56:14 5: PILIGHT(Parse): protocol:kaku_switch,id:58060626,unit:15
2018.01.02 17:56:14 4: PILIGHT(Dispatch): PISWITCH,kaku_switch,58060626,15,off
2018.01.02 17:56:14 5: PILIGHT: dispatch PISWITCH,kaku_switch,58060626,15,off
2018.01.02 17:56:15 5: PILIGHT(SendNonBlocking): queue size 1
2018.01.02 17:56:15 5: PILIGHT(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":58060626,"unit":15,"off":1}}
2018.01.02 17:56:15 4: PILIGHT(Send): RCV -> {"status":"success"}
2018.01.02 17:56:15 4: PILIGHT(SendDone): message successfully send
2018.01.02 17:56:16 5: PILIGHT(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":58060626,"unit":15,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-e0896f"}
2018.01.02 17:56:16 5: PILIGHT(Parse): protocol:kaku_switch,id:58060626,unit:15
2018.01.02 17:56:16 4: PILIGHT(Dispatch): PISWITCH,kaku_switch,58060626,15,off
2018.01.02 17:56:16 5: PILIGHT: dispatch PISWITCH,kaku_switch,58060626,15,off
z.b. einschalten
2018.01.02 17:57:25 5: PILIGHT(Parse): protocol:kaku_switch,id:58060626,unit:15
2018.01.02 17:57:25 4: PILIGHT(Dispatch): PISWITCH,kaku_switch,58060626,15,on
2018.01.02 17:57:25 5: PILIGHT: dispatch PISWITCH,kaku_switch,58060626,15,on
2018.01.02 17:57:25 4: PILIGHT(SendDone): message successfully send
2018.01.02 17:57:26 5: PILIGHT(SendNonBlocking): queue size 2
2018.01.02 17:57:26 5: PILIGHT(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":58060626,"unit":15,"on":1}}
2018.01.02 17:57:26 4: PILIGHT(Send): RCV -> {"status":"success"}
2018.01.02 17:57:26 4: PILIGHT(SendDone): message successfully send
2018.01.02 17:57:26 5: PILIGHT(SendNonBlocking): queue size 1
2018.01.02 17:57:26 5: PILIGHT(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":58060626,"unit":15,"on":1}}
2018.01.02 17:57:27 4: PILIGHT(Send): RCV -> {"status":"success"}
2018.01.02 17:57:27 5: PILIGHT(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":58060626,"unit":15,"state":"on"},"repeat":1,"uuid":"0000-b8-27-eb-e0896f"}
2018.01.02 17:57:27 5: PILIGHT(Parse): protocol:kaku_switch,id:58060626,unit:15
2018.01.02 17:57:27 4: PILIGHT(Dispatch): PISWITCH,kaku_switch,58060626,15,on
2018.01.02 17:57:27 5: PILIGHT: dispatch PISWITCH,kaku_switch,58060626,15,on
Es funktioniert erst alles wieder, wenn ich mit der original Fernbedienung einen Schaltbefehl sende.
2018.01.02 17:57:27 5: PILIGHT(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":58060626,"unit":15,"state":"on"},"repeat":1,"uuid":"0000-b8-27-eb-e0896f"}
2018.01.02 17:57:27 5: PILIGHT(Parse): protocol:kaku_switch,id:58060626,unit:15
2018.01.02 17:57:27 4: PILIGHT(Dispatch): PISWITCH,kaku_switch,58060626,15,on
2018.01.02 17:57:27 5: PILIGHT: dispatch PISWITCH,kaku_switch,58060626,15,on
2018.01.02 17:57:27 4: PILIGHT(SendDone): message successfully send
2018.01.02 17:59:23 5: PILIGHT(Parse): RCV -> {"message":{"id":37472078,"unit":15,"state":"up"},"origin":"receiver","protocol":"arctech_screen","uuid":"0000-b8-27-eb-e0896f","repeats":1}
2018.01.02 17:59:23 5: PILIGHT(Parse): protocol:arctech_screen,id:37472078,unit:15
2018.01.02 17:59:23 5: PILIGHT: dispatch PISCREEN,arctech_screen,37472078,15,up
2018.01.02 17:59:23 3: PILIGHT: Unknown code PISCREEN,arctech_screen,37472078,15,up, help me!
2018.01.02 17:59:23 5: PILIGHT(Parse): RCV -> {"message":{"id":37472078,"unit":15,"state":"on"},"origin":"receiver","protocol":"arctech_switch","uuid":"0000-b8-27-eb-e0896f","repeats":1}
2018.01.02 17:59:23 5: PILIGHT(Parse): protocol:kaku_switch,id:37472078,unit:15
2018.01.02 17:59:23 4: PILIGHT(Dispatch): PISWITCH,kaku_switch,37472078,15,on
2018.01.02 17:59:23 5: PILIGHT: dispatch PISWITCH,kaku_switch,37472078,15,on
2018.01.02 17:59:23 5: PILIGHT(Parse): RCV -> {"message":{"id":37472078,"unit":15,"state":"opened"},"origin":"receiver","protocol":"arctech_contact","uuid":"0000-b8-27-eb-e0896f","repeats":1}
2018.01.02 17:59:23 5: PILIGHT(Parse): protocol:arctech_contact,id:37472078,unit:15
2018.01.02 17:59:23 4: PILIGHT(Dispatch): PICONTACT,arctech_contact,37472078,15,opened
2018.01.02 17:59:23 5: PILIGHT: dispatch PICONTACT,arctech_contact,37472078,15,opened
2018.01.02 17:59:23 3: PILIGHT: Unknown code PICONTACT,arctech_contact,37472078,15,opened, help me!
Wenn ich jetzt wieder im Frontend schalte funktioniert wieder alles.
2018.01.02 17:59:41 4: PILIGHT(Write): RCV (pilight_switch) -> tr_lampe,off
2018.01.02 17:59:41 4: PILIGHT(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":58060626,"unit":15,"off":1}}
2018.01.02 17:59:41 5: PILIGHT(SendNonBlocking): queue size 1
2018.01.02 17:59:41 4: PILIGHT(Write): RCV (pilight_switch) -> tr_lampe,off
2018.01.02 17:59:41 4: PILIGHT(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":58060626,"unit":15,"off":1}}
2018.01.02 17:59:41 5: PILIGHT(SendNonBlocking): queue size 1
2018.01.02 17:59:41 5: PILIGHT(Write): Blocking Call running - will try it later
2018.01.02 17:59:41 4: PILIGHT(Write): RCV (pilight_switch) -> tr_lampe,off
2018.01.02 17:59:41 4: PILIGHT(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":58060626,"unit":15,"off":1}}
2018.01.02 17:59:41 5: PILIGHT(SendNonBlocking): queue size 2
2018.01.02 17:59:41 5: PILIGHT(Write): Blocking Call running - will try it later
2018.01.02 17:59:41 5: PILIGHT(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":58060626,"unit":15,"off":1}}
2018.01.02 17:59:41 4: PILIGHT(Send): RCV -> {"status":"success"}
2018.01.02 17:59:41 5: PILIGHT(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":58060626,"unit":15,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-e0896f"}
2018.01.02 17:59:41 5: PILIGHT(Parse): protocol:kaku_switch,id:58060626,unit:15
2018.01.02 17:59:41 4: PILIGHT(Dispatch): PISWITCH,kaku_switch,58060626,15,off
2018.01.02 17:59:41 5: PILIGHT: dispatch PISWITCH,kaku_switch,58060626,15,off
2018.01.02 17:59:41 4: PILIGHT(SendDone): message successfully send
2018.01.02 17:59:42 5: PILIGHT(SendNonBlocking): queue size 2
2018.01.02 17:59:42 5: PILIGHT(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":58060626,"unit":15,"off":1}}
2018.01.02 17:59:42 4: PILIGHT(Send): RCV -> {"status":"success"}
2018.01.02 17:59:42 4: PILIGHT(SendDone): message successfully send
2018.01.02 17:59:42 5: PILIGHT(SendNonBlocking): queue size 1
2018.01.02 17:59:42 5: PILIGHT(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":58060626,"unit":15,"off":1}}
Ich bin hier langsam am verzweifeln und habe keine Idee mehr.
Eventuell könnt Ihr ja etwas entdecken....
Hoffentlich habe ich das Problem ausreichend beschrieben.
p.s.
im PILIGHT device habe ich noch folgendes unter "brands" eingetragen, da ansonsten die Zustände nicht angezeigt werden:
arctech_switch:kaku_switch
Danke
mschmitz
Hallo mschmitz.
ich kann leider in den Logs nichts ungewöhnliches finden. Sieht für mich eher nach einem Problem mit pilight direkt aus.
Geht denn "pilight-send" nach dem reboot bzw. wenn es aus FHEM nicht geht?
Vielleicht hilft dir das.
https://www.google.de/url?sa=t&source=web&rct=j&url=https://askubuntu.com/questions/204481/how-to-install-perl-switch-pm-module-required-to-build-webkit-gtk&ved=0ahUKEwiYxp6Cu7zYAhXQ2qQKHfUeChcQFggtMAE&usg=AOvVaw1IW_SwvmpuPIF2qYPPZcXW
Hallo,
ich habe ein ähnliches Problem mit den selbstlernenden Kakus aus dem Obi.
Versuche erstmal die Schalter in Pilight abzubilden und zu schalten. (Also mit dem Webinterface von Pilight)
Wenn es da schon hängt, kann das Pilightmodul von FHEM nichts dran machen.
Dann könntest du im Pilight.org Forum fragen.
LG,
Ingo
Hallo,
danke für die Rückmeldungen.
Ich habe mal einen Schalter im pilight-webinterface eingebunden - auch hier tritt das Problem auf.
Was mir aufgefallen ist: Es betrifft nur diese kaku arctech Switche. Meine elro's funktionieren immer sofort.
Der Unterschied ist hierbei, dass die Kaku's selbstlernend sind und die elro's noch DIP Schalter haben.
mhh ?
Hallo,
ich nutze seit längeren dieses Modul für 433 Mhz Steckdosen und Wetter stationen.
Nun habe ich an meinem RPI ein BH1750 Lichtsensor am I2C Bus angeschlossen und kann diesen auch mit pilight pollen. Es handelt sich um ein 3rd party Module "bh1750".
Um das ganze nun auch in FHEM lesbar zu machen, habe ich einige kleine Änderungen an folgendem file vorgenommen:
10_pilight_ctrl.pm:
add line 861: case m/bh1750/ {$protoID = 4;}
add line 919: $piTempData .= ",illuminance:$data->{$s}{illuminance}" if (defined($data->{$s}{illuminance}));
Jetzt kann ich einfach mit folgendem def den BH1750 auslesen:
define flur.helligkeit.02 pilight_temp bh1750 0x23
attr flur.helligkeit.02 IODev dev.pilight.01
Meine Frage ist, wäre es möglich das so im Repository aufzunehmen?
Als Referenz zum pilight module, hier ein Thread Beitrag:
https://forum.pilight.org/showthread.php?tid=2738
Danke + Gruß
Florian
Hallo albundy118,
erstmal Danke dafür.
Ich bin noch am überlegen. So ganz gefällt es mir nicht, mit einem für Temperatur bzw. Wetterstation ausgelegtem Modul Helligkeitswerte darzustellen.
Risiko
Hallo Risiko,
also für mich spricht auch nichts dagegen dass ganze in ein extra modul auszulagern. Ich fand nur das wäre für diesen einen Sensor etwas overkill.
Soll ich mal ein Vorschlag für ein modul pilight_illuminance machen? Das wären dann aber etwas mehr Änderungen im file ctrl, aber wäre denke ich machbar.
Gruß
Florian
Hallo Florian,
ja für nur einen Sensor ist das zu viel Aufwand Daher hadere ich auch noch bzw. würde das Modul auch nicht so nennen.
Wenn dann erstmal allgemeiner (man weiß ja nicht, was noch kommt) wie z.B. pilight_miscellaneous oder pilight_other.
Helligkeit fällt eben aus der bis jetzt vorliegenden Gruppierung raus.
Auf der anderen Seite kann man es eben erstmal so integrieren und später schauen wo die Reise hin geht.
Gib mir mal noch das Wochenende. ;)
Risiko
Ich habe mal eine allgemeine Frage?
Welche Hardwarelösung nutzt ihr am RPI?
Sender und Empfänger direkt an den GPIO?
ODER mit atiny dazwischen
Oder über USB
Oder sogar über WLAN?
Hintergrund bei mir direkt an den Gpio geht öfters garnix mehr Signale kommen nicht in FHEM an und was häufiger der Fall ist Signale werden nicht gesendet.
Hi Risiko,
also ich bin für alles offen und helfe auch gerne wo ich kann. Danke schon mal dass du es dir anschaust, eilt auch nicht.
@Tueftler, also ich nutze 2 RPIs (1x pilight master, 1x pilight slave) an deren jeweils ein 433 Mhz receiver + sender mit GPIO dran sind. Beim Master habe ich einen etwas teueren Empfänger dran, da die billig receiver nur sehr wenig reichweite haben.
Ich bin soweit sehr zu frieden, ich nutze das Setup um Funksteckdosen zu schalten und Temp Sensoren auszulesen.
Gruß
Florian
Zitat von: stratege-0815 am 08 September 2017, 14:25:49
Okay, ich habe nochmal eben gecheckt, ich habe damals das einfach Modul "pilight" verwendet. Die Schalter sind so eingerichtet:
define Regalbeleuchtung pilight brennenstuhl
attr Regalbeleuchtung room Homekit,Esszimmer
attr Regalbeleuchtung systemcode 31
attr Regalbeleuchtung unitcode 2
Das heisst ich muss die erst einmal alle "umbauen"....
So, ich hole noch einmal mein altes Posting hoch. Verschiedene Umstände ergaben das ich meinen Pi komplett neu aufgesetzt habe. Teile der alten fhem.cfg habe ich übernommen. Alles läuft nun auf fhem 5.8, hardwaremäßig immer noch ein 433mhz Sender über GPIO mit Pilight als Unterbau. Alle Funksteckdosen schalten sowohl über pilight wie auch fhem. Der Übersichtlickeit halber habe ich sie in einem Raum "pilight" versammelt.
Jedoch habe ich immer noch Probeme mit dem Status. Ein in pilight ausgelöstes event sollte doch auch in fhem ankommen, dafür läuft ja die Kommunikation über port 5000. Tatsächlich zeigen aber fast alle devices nur den status "defined". Im Anhang ein paar Bilder.
Pilight ist jetzt auch schon Version 8.0, weil die alte Version wohl nach einem Kernelupdate auf 4.9 ein Problem hatte.
Oder habe ich irgendwo noch etwas vergessen?
Gruß
Jan
Hi stratege-0815,
also dein "pilight_connector" ist im status "closed". Das heißt der connector ist nicht mit dem pilight process verbunden. Somit sollte weder senden noch empfangen funktionieren. Wenn pilight-daemon läuft, solltest du mal prüfen ob du den richtigen Port angegeben hast.
Das module "pilight" welches du erwähnst hat aber soweit ich verstanden habe, nichts mit diesem pilight_xxx module zu tun.
Zitat von: albundy118 am 22 Januar 2018, 23:27:39
Hi stratege-0815,
also dein "pilight_connector" ist im status "closed". Das heißt der connector ist nicht mit dem pilight process verbunden. Somit sollte weder senden noch empfangen funktionieren. Wenn pilight-daemon läuft, solltest du mal prüfen ob du den richtigen Port angegeben hast.
Das module "pilight" welches du erwähnst hat aber soweit ich verstanden habe, nichts mit diesem pilight_xxx module zu tun.
Danke für die Rückmeldung. "Ja" und "Ja" :D
Also der "pilight_conector" ist ja das Modul pilight_ctrl, dieses bietet die Möglichkeit eines reset oder disconnect. Ich hatte beides einmal ausprobiert um zu gucken ob sich danach die readings wieder aktualisieren. Leider Fehlanzeige.
Das alte Modul "pilight" kommt überhaupt nichtmehr zum Einsatz, da ja wie geschrieben alles neu installiert wurde. Pilight kommuniziert über Port 5000, ich kann ja mittels fhem meine pilight Steckdosen schalten. Ich befürchte fast das pilight 8.0 hier vielleicht zu neu ist und Probleme macht.
Also wenn der pilight_ctrl connected, habe ich nix gesagt ;-)
Ich denke dann liegt es daran dass pilight intern keine message schickt wenn du in pilight selbst schaltest. Ich nutzt das auch gar nicht, ich schalte entweder mit FHEM oder mit der Fernbedienung. Wenn ich mit der Fernbedienung schalte, wird der status sauber in FHEM angezeigt. Ich nutzte die letzte nightly 8.0.7
Also wenn du nicht unbedingt in pilight schalten willst, kannst du alle Geräte rausschmeißen, ich habe da nix drin:
{
"devices": {},
"rules": {},
"gui": {},
"settings": {
"log-level": 4,
"pid-file": "/var/run/pilight.pid",
"log-file": "/var/log/pilight.log",
"port": 5555,
"webserver-enable": 0,
"gpio-platform": "raspberrypi3"
},
"hardware": {
"433gpio": {
"sender": 0,
"receiver": 1
}
},
"registry": {
"webserver": {
"ssl": {
"certificate": {
"secure": 0,
"location": "/etc/pilight/pilight.pem"
}
}
},
"pilight": {
"version": {
"current": "8.0.7"
}
}
}
}
Zitat von: albundy118 am 17 Januar 2018, 09:43:47
Hallo,
ich nutze seit längeren dieses Modul für 433 Mhz Steckdosen und Wetter stationen.
Nun habe ich an meinem RPI ein BH1750 Lichtsensor am I2C Bus angeschlossen und kann diesen auch mit pilight pollen. Es handelt sich um ein 3rd party Module "bh1750".
.....
Meine Frage ist, wäre es möglich das so im Repository aufzunehmen?
Als Referenz zum pilight module, hier ein Thread Beitrag:
https://forum.pilight.org/showthread.php?tid=2738
Danke + Gruß
Florian
Hallo Florian,
ich habe es doch erstmal so, wie du es vorgeschlagen hast, in pilight_ctrl aufgenommen.
Mal schauen, was die Zukunft bringt. Evtl. fliegt es da auch wieder raus, wenn es mehrer Sensoren mal gibt.
Risiko
Hallo zusammen,
wäre es möglich, zusätzlich zu dem Blacklistansatz vom ignoreProtocol Attribut in pilight_ctrl auch noch ein Whitelist Attribut zu implementieren? Das würde das Filtern der Events für mein log unheimlich erleichtern, da ich hier einige Protokolle empfange, die ich nicht benötige.
Viele Grüße
mayonezo
Danke Risiko! Habe gerade update gemacht und kann bestätigen dass es weiterhin funktioniert.
Gruß
Florian
Zitat von: Risiko am 03 März 2015, 20:33:54
Hallo.
Ich möchte hier die Module zum Senden und Empfangen mittels pilight vorstellen.
pilight_ctrl: - Basismodul für die Kommunikation
define <name> pilight_ctrl <host:port> [api]
- host - IP wo der pilight-daemon läuft
- port - Port des pilight-daemon
- api - pilight version optional, 5.0 oder 6.0 - default 6.0
pilight_switch: - Repräsentation eines Schalters
define <name> pilight_switch <protocol> <id> <unit>
- protocol - Protokoll z.B. kaku_switch
- id - ID oder Systemcode je nach Protokoll
- unit - unit, unitcode oder programcode je nach Protokoll
pilight_dimmer: - Repräsentation eines Dimmers
define <name> pilight_dimmer <protocol> <id> <unit>
Parameter wie beim Schalter.
pilight_temp: - Repräsentation eines Temperatur- und Luftfeuchtigkeitssensors bzw. Wetterstation
define <name> pilight_temp <protocol> <id>
Bei GPIO Sensoren muss als id der GPIO-Pin angegeben werden.
pilight_raw: - Modul zum Senden von raw codes
define <name> pilight_raw
Weitere Dokumentation in den Modulen selbst.
Wichtig ist noch das Attribut "brands" in pilight_ctrl.
Damit wird das Problem gelöst, dass pilight für ein und das selbe Protokoll (für Senden und Empfangen) unterschiedliche Namen verwendet (z.B. arctech, kaku, intertechno).
Beispiel:
Senden mit Protokoll kaku_switch_old, Empfang für das gleiche Device mit arctech_switch_old.
Dann muss arctech durch kaku ersetzt werden. Das erreicht man mit brands arctech:kaku.
Ich habe Einiges getestet und bei mir läuft es aktuell mit drei Intertechno Schaltern und einem Intertechno Dimmer soweit stabil.
Leider habe ich nicht so viel unterschiedliche Hardware - also keine Garantie, dass es mit allen Protokollen (schon) funktioniert.
Die in 6.0 eingeführten Kontakte können als Schalter "umgebogen" werden. Attribut "ContactAsSwitch" in pilight_ctrl.
Viel Spaß.
History:
16.03.15 FIX ID alphanumerisch
20.03.15 NEW Protokoll 'clerverwatts' hinzugefügt
26.03.15 NEW Protokoll 'clerverwatts' unit all für 'all'-Signal
29.03.15 NEW Temperatur- und Luftfeuchtigkeitssensoren
30.03.15 NEW GPIO - Temperatur- und Luftfeuchtigkeitssensoren
30.03.15 NEW Komplette Protokolle ignorieren mit Attribut ignore <protokoll_name>:*
09.04.15 FIX Nur Senden, wenn auch eine Verbindung zum pilight-daemon besteht
12.04.15 FIX Protokoll 'intertechno_old' hinzugefügt
17.04.15 FIX Kleinere Rechtschreibfehler - Danke an pattex
17.04.15 FIX Senden mehrerer Befehle in kurzer Zeit (Aufbau einer Messagequeue)
29.04.15 CHG Attribut ignore zu ignoreProtocol umbenannt, da ignore bereits vergeben ist
09.05.15 NEW ignoreProtocol * - es wird bis auf die durch Submodule definierten Protokoll-ID-Kombinationen alles andere ignoriert
09.05.15 NEW Protokoll quigg_gt* (z.B. quigg_gt7000) ergänzt
16.05 15 NEW pilight_temp: Status der Batterie als reading, Attribut 'corrTemp' zur Korrektur der Temperatur
17.05.15 NEW pilight_temp: Attribut 'corrHumidity' zur Korrektur der Luftfeuchte
20.05.15 NEW pilight_dimmer: Möglichkeit den Dimmer mit der Screen Funktionalität (up|down) zu erweitern
30.05.15 FIX pilight_dimmer: Funktionalität (up|down) + set dimlevel 0
30.05.15 FIX pilight_switch|dimmer: Trigger|Notify wurde immer zweimal ausgelöst
07.06.15 FIX pilight_ctrl: set reset - Verbindung zu Submodulen wurde unterbrochen
20.06.15 NEW pilight_ctrl: set disconnect - Verbindung trennen und nicht automatisch wieder aufbauen
23.06.15 NEW pilight_ctrl: Attribut SendTimeout - Abbruchzeit für Sendebefehl - Default 1s
23.06.15 FIX pilight_ctrl: Sendequeue bei reset leeren
21.07.15 NEW pilight_raw: Modul zum Sende von raw codes
27.07.15 NEW pilight_dimmer|switch|raw: SetExtensions(on-for-timer, off-for-timer,etc)
30.08.15 NEW pilight_temp: Luftdruck, Windrichtung, Windgeschwindigkeit, Windböe (falls von Sensor unterstützt)
06.09.15 FIX pilight_temp: pressure, windavg, winddir, windgust from weather stations without temperature
29.11.15 NEW pilight_temp: add attributes offsetTemp and offsetHumidity to correct temperature and humidity
17.12.15 NEW 30_pilight_xyz: IO-Device über Attribut verstellen
20.03.16 FIX pilight_ctrl: send delimiter to signal end of stream if length of data > 1024 (e.q. long raw codes)
28.03.16 NEW pilight_switch: protocol daycom
02.06.16 NEW pilight_ctrl: protocol oregon_21
03.07.16 NEW pilight_smoke: new module - representation of a pilight smoke detector
13.11.16 NEW pilight_contact: Neues Modul für Kontaksensoren
Module ab 26.04.15 in FHEM integriert und per update erhältlich
Ich bin neu in FHEM und habe früher mal in den Anfängen ein wenig mit pilight und pimatik gemacht. Aus der Zeit habe ich auch noch die Hardware. Wenn ich es richtig verstehe, kann man in FHEM mit dem pilight Server kommunizieren und über diesen mit der pilight hardware senden und empfangen. Dann lohnt es sich vielleicht, die alte Hardware wieder zu aktivieren, da es in pilight inzwischen auch module für Protokolle gibt, die ich mit meinen nanoCUL vielleicht nicht senden kann, z.B. Auriol Wetter.
Habe ich das so richtig verstanden?
Hallo,
ich brauche bitte mal Hilfe:
Pilight V7 auf Raspberry Pi 3 installiert und läuft.
In Fhem "define Pilight pilight_ctrl 192.168.0.7:5001" lässt Fhem abstürzen und auch nicht mehr starten.
Reboot Pi notwendig.
Hatte auch die V8 installiert, das Gleiche Ergebnis.
Logauszug fhem:
2018.01.31 15:25:24 3: Opening Pilight device 192.168.0.7:5001
2018.01.31 15:25:24 3: Pilight device opened
malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "HTTP/1.0 404 Not Fou...") at ./FHEM/10_pilight_ctrl.pm line 736.
Dann schmiert Fhem ab.
Was muss ich tun?
Danke & Gruss
Andreas
Ich denke hier ist der Port 5001 falsch. http://192.168.0.7:5001 dürfte deine pilight GUI sein. die API läuft aber über den Port 5000 , der sollte auch in deiner config.json in pilight definiert sein. Siehe https://manual.pilight.org/configuration/settings.html#port
Zitat von: McShire am 29 Januar 2018, 23:10:34
Ich bin neu in FHEM und habe früher mal in den Anfängen ein wenig mit pilight und pimatik gemacht. Aus der Zeit habe ich auch noch die Hardware. Wenn ich es richtig verstehe, kann man in FHEM mit dem pilight Server kommunizieren und über diesen mit der pilight hardware senden und empfangen. Dann lohnt es sich vielleicht, die alte Hardware wieder zu aktivieren, da es in pilight inzwischen auch module für Protokolle gibt, die ich mit meinen nanoCUL vielleicht nicht senden kann, z.B. Auriol Wetter.
Habe ich das so richtig verstanden?
Ja, genau so sollte das funktionieren. Am besten siehst du zuerst mal zu das es in pilight funktioniert, darauf kannst du dann FHEM setzen
Zitat von: stratege-0815 am 31 Januar 2018, 17:00:44
Ja, genau so sollte das funktionieren. Am besten siehst du zuerst mal zu das es in pilight funktioniert, darauf kannst du dann FHEM setzen
Ja, das wars. Danke :-)
Einen Schritt weiter.
Zitat von: albundy118 am 23 Januar 2018, 21:53:49
Also wenn der pilight_ctrl connected, habe ich nix gesagt ;-)
Ich denke dann liegt es daran dass pilight intern keine message schickt wenn du in pilight selbst schaltest. Ich nutzt das auch gar nicht, ich schalte entweder mit FHEM oder mit der Fernbedienung. Wenn ich mit der Fernbedienung schalte, wird der status sauber in FHEM angezeigt. Ich nutzte die letzte nightly 8.0.7
Ich bin hier jetzt auch einen kleinen Schritt weiter. Habe pilight nochmal upgedatet sollte jetzt 8.0.8 sein. Der pilight_ctrl ist connected. Der hat auch ein reading, irgendwas "raw..." und dort taucht auch immer der letzte Schaltvorgang mit entsprechendem device auf den ich via pilight GUI durchgeführt habe. Allerdings wird er nicht in der Darstellung auf meine devices in FHEM übertragen. Mir scheint das Problem eher au dem FHEM Seite zu liegen.
Muss ich für die pilight devices in FHME erst noch readings anlegen?
Auch wenn ihr mich jetzt haut, hab ich noch ne Frage:
Benötige ich ein separates 433Mhz Sende/Empfangsteil oder reicht auch der CUL am USB des Raspberrys, der aktuell für FHEM läuft?
Also verarbeitet Pilight die Signale, die am 433Mhz CUL empfangen werden?
Sorry....
Zitat von: stratege-0815 am 31 Januar 2018, 17:00:44
Ja, genau so sollte das funktionieren. Am besten siehst du zuerst mal zu das es in pilight funktioniert, darauf kannst du dann FHEM setzen
Danke für die Info.
Ich habe jetzt den Signalduino fertig, der hat die fehlenden Temperatursensoren auf Anhieb erkannt, setze diesen jetzt ein.
Aber pilight unter FHEM werde ich jetzt trotzdem ausprobieren, allein schon aus Neugierde.
PS: mit dem Signalduino wurde jetzt auch mein 12V 1CH Funkrelais (4,50 EUR bei Ebay) erkannt und kann als IT device geschaltet werden.
Vielleicht ist dies Info für jemanden nützlich.
https://www.ebay.de/itm/1CH-12V-Funk-Wireless-RF-Relais-Schalter-Sender-Empfanger-Fernbedienung-433MHZ/401442955607?hash=item5d77dd6157:g:PgsAAOSwOA1aC~ob
Gruß
Werner
Zitat von: albundy118 am 23 Januar 2018, 21:53:49
Also wenn der pilight_ctrl connected, habe ich nix gesagt ;-)
Ich denke dann liegt es daran dass pilight intern keine message schickt wenn du in pilight selbst schaltest. Ich nutzt das auch gar nicht, ich schalte entweder mit FHEM oder mit der Fernbedienung. Wenn ich mit der Fernbedienung schalte, wird der status sauber in FHEM angezeigt. Ich nutzte die letzte nightly 8.0.7
Also wenn du nicht unbedingt in pilight schalten willst, kannst du alle Geräte rausschmeißen, ich habe da nix drin:
{
"devices": {},
"rules": {},
"gui": {},
"settings": {
"log-level": 4,
"pid-file": "/var/run/pilight.pid",
"log-file": "/var/log/pilight.log",
"port": 5555,
"webserver-enable": 0,
"gpio-platform": "raspberrypi3"
},
"hardware": {
"433gpio": {
"sender": 0,
"receiver": 1
}
},
"registry": {
"webserver": {
"ssl": {
"certificate": {
"secure": 0,
"location": "/etc/pilight/pilight.pem"
}
}
},
"pilight": {
"version": {
"current": "8.0.7"
}
}
}
}
Ich habe mein Problem jetzt lösen können (und dafür schon direkt das nächste).
Bei meinen Definitionen der Schalter habe ich mich an die Protokolle gehalten die auch in pilight definiert sind. ,,Silvercrest" und ,,brennenstuhl". Die hatte ich seinerzeit aus der jeweiligen Fernbedienung ausgelesen. Offenbar macht das brennenstuhl Protokoll Probleme, Umstellung auf silvercrest brachte Abhilfe. Alles schaltet und der Status aus pilight kommt in FHEM an.
Nun da das funktioniert nächstes ,,Problem" gibt die api den Status auch von FHEM an pilight gui ?
Bei mir tut es das nämlich nicht. Ich weiß aber auch gar nicht ob das vorgesehen ist.
Zitat von: stratege-0815 am 11 Februar 2018, 08:32:38
Nun da das funktioniert nächstes ,,Problem" gibt die api den Status auch von FHEM an pilight gui ?
Bei mir tut es das nämlich nicht. Ich weiß aber auch gar nicht ob das vorgesehen ist.
Ja und geht. Sowohl mit pilight 7 (vorm upgrade) und pilight 8.0.8 getestet.
Zitat von: Risiko am 11 Februar 2018, 14:32:14
Ja und geht. Sowohl mit pilight 7 (vorm upgrade) und pilight 8.0.8 getestet.
Auch das konnte ich jetzt lösen, ich musste noch in pilight das Protokoll anpassen. Mit ,,silvercrest" durchgängig funktioniert es nun. Und sogar die noch obendrauf gestülpte homebridge zeigt nun in Apple Home den richtigen Status meiner Funkschalter, egal ob in fhem oder pilight geschaltet.
Liebe mit Forum user und Admins
ich hoffe ich platziere meine Frage hier richtig
also pilight geupdatet
.json bearbeitet
libjson.perl update gezogen
Was bisher bei mir läuft.... ist eine selbstlernende intertechno lampen IT1500 IT1000 IT3500
define Esszimmer dummy
attr Esszimmer group Beleuchtung
attr Esszimmer room Küche
attr Esszimmer setList on off
attr Esszimmer useSetExtensions 1
define off_Esszimmer notify Esszimmer:off { system("pilight-send -p kaku_switch -i XXXXXXX -u 0 -f")}
define on_Esszimmer notify Esszimmer:on { system("pilight-send -p kaku_switch -i XXXXXXX-u 0 -t")}
diesen code um pilight anzusteuern habe ich im netz gefunden
Was ich nicht ans laufen bekomme Voltomat
define voltomat switch GT-Fsi-06
attr voltomat group Beleuchtung
attr voltomat room Wohnzimmer
attr voltomat setList on off
attr voltomat useSetExtensions 1
define off_voltomat notify voltomat:off { system("pilight-send -p qiugg_gt9000 -i 262934 -u 0 -f")}
define on_voltomat notify voltomat:on { system("pilight-send -p qiugg_gt9000 -i 262934 -u 0 -t")}
das sind die daten die mein pilight-receive ausspuckt
"message": {
"binary": "010001101111100110110000",
"id": 262934,
"unit": 0,
"state": "on"
},
"origin": "receiver",
"protocol": "quigg_gt9000",
"uuid": "0000-b8-27-eb-9074d9",
"repeats": 2
habe probleme beim starten von pilight
pilight.service changed on disk. Run 'systemctl daemon-reload' to reload units.
erst nach einem restart kommt er ans fliegen
Meine Frage hier an Risiko
kannst du mir helfen.
ich bin noch ziemlich neu in der Materie:)
by the way habe es hier platziert weil mein englisch rotze ist.
Liebe Grüße Juli
Hallo Juli,
zuerst muss pilight selbst laufen -- ggf. im pilight Forum um Hilfe bitten.
Dann ein pilight_ctrl in FHEM anlegen. z.B.
define pilightCtrl pilight_ctrl localhost:5000
Anschließend einzelnen Geräte definieren
define Esszimmer pilight_switch kaku_switch <id> <unit>
Das Protokoll "qiugg_gt9000" ist hier https://manual.pilight.org/protocols/index.html nicht gelistet.
Das müsste ich erst noch einbauen.
Hallo Risiko
Ich finde aktuell den befehl nicht wo ich mir anschauen kann in der console welche protokolle pilight unterstützt
habe heute ein update gefahren und da war quigg_Gt9000 dabei nur das dahinter ein Kommentar mit einem switch steht.
muss mich morgen mal mit wachen kopf dran setzen.
aber danke schon einmal ich melde mich morgen noch einmal
Hey Leute
also ich habe es jetzt bei mir auch, soweit das Pilight läuft und mir auch die Temperatur anzeigt, nur habe ich jetzt das Problem das sobald ich
define myctrl pilight_ctrl 192.168.178.57:5000 8.1
egal ob ich die Version angebe oder IP bzw. Localhost sobald ich mit Enter bestätige war es das und FHEM ist abgestürzt und ich muss per Putty ein Reboot machen Pilight selber läuft einfach weiter, ich hoffe ihr habt noch eine Idee was ich mal wieder falsch mache :o
Caleus
Hallo Caleus,
was steht den im Log?
Ohne weitere Infos kann ich leider nicht helfen.
@Risiko
Hallo ich habe hier
https://forum.fhem.de/index.php?topic=87427.msg807184#msg807184 (https://forum.fhem.de/index.php?topic=87427.msg807184#msg807184)
weiter geschrieben.
Caleus
Hallo,
ich hätte da gern nochmal ein Problem :-) :
Es geht um folgenden Schalter:
define Licht_Buero pilight_switch elro_800_switch 23 4
attr Licht_Buero IODev pilight_oben
attr Licht_Buero alias Bürolicht
attr Licht_Buero devStateIcon on:general_an@red off:general_aus@grey
attr Licht_Buero group Schalter
attr Licht_Buero icon light_ceiling
attr Licht_Buero room Schlafzimmer
Wenn ich per Webinterface oder FTUI schalte, funktioniert es einwandfrei.
Schalte ich das per Timer oder per DOIF bekomme ich im Log:
pilight_oben(Write): RCV (pilight_switch) -> Licht_Buero,on
pilight_oben(Write): {"action":"send","code":{"protocol":["elro_800_switch"],"systemcode":23,"unitcode":4,"on":1}}
pilight_oben(SendNonBlocking): queue size 1
Timeout for pilight_ctrl_Send reached, terminated process 16900
pilight_oben(SendAbort): ERROR. sending aborted
Das geht auch bei mehreren Schaltern so, Gartenteichbeleuchtung, Schrankwand im Wohnzimmer...
Das ist Pilight auf der selben PI.
Im Wohnzimmer hängt noch eine als Slave. Die sind gekoppelt.
define pilight_oben pilight_ctrl 192.168.0.200:5000
attr pilight_oben verbose 5
Was kann das sein?
Hallo eisi,
ich kann in den Logauszügen leider keinen Fehler erkennen. Ggf. kannst du mal das Timeout (Attribut SendTimeout) höher setzen.
Gibt es denn Einträge mit queue size > 1?
Wie sieht denn dein timer aus? Bekomme es bei mir nicht nachgestellt.
Risiko
define Einbruchschutz DOIF ([Handy_Ingo] eq "absent") (set Licht_Buero on) DOELSE (set Licht_Buero off)
Da scheitert es schon.
Ich setze mal das Attribut hoch.
Die Verlängerung des Timeouts auf 10s hat geholfen.
Danke!
Hey,
hier ist ja seit längerem nichts mehr los (sind wahrscheinlich alle jetzt mit Wlan- Steckdosen unterwegs).
Dennoch hätte ich da noch eine Frage:
Ich habe hier ein paar Steckdosen, die sich über PiLight mit
sudo pilight-send -p kaku_screen -i 20878336 -u 1 -f
sudo pilight-send -p kaku_screen -i 20878336 -u 1 -t
steuern lassen.
Über FHEM bekomme ich die aber mit pilight-switch nicht definiert.
Kann da jemand helfen?
Du benötigst auch das Basismodul pilight_ctrl. Hast du dieses definiert?
Erst dann kann man pilight_switch, etc. verwenden.
Risiko
Zitat von: Risiko am 03 Juli 2019, 21:52:36
Du benötigst auch das Basismodul pilight_ctrl. Hast du dieses definiert?
Erst dann kann man pilight_switch, etc. verwenden.
Risiko
Achso, ja, ich verwende das Modul mit anderen Steckdosen (noch ganz alte Elro's mit Dip-Schaltern) schon recht lange ohne Probleme.
defmod ATest pilight_switch elro_800_switch 18 1 funktioniert super.
defmod Test pilight_switch kaku_screen 20878336 2 hingegen funktioniert nicht. Es wird einfach nichts gesendet (lt. Eventmonitor).
Übrigens:
defmod Test pilight_switch kaku_switch 20878336 2 Sendet fleißig, aber leider lässt sich damit meine Steckdose nicht schalten.
Das muss also m.E. irgendwie mit dem Protokoll kaku_screen zusammenhängen. Und mit dem pilight Modul(en), weil es mit pilight selbst über die shell ja läuft.
kaku_screen ist kein Protokoll für Schalter!
Siehe auch https://manual.pilight.org/protocols/index.html
Deshalb geht es auch mit piligt_switch nicht!
Du solltest kaku_switch_old oder ggf. ein Alias\Brands dazu verwenden. Siehe z.B. https://manual.pilight.org/protocols/433.92/switch/intertechno.html
https://manual.pilight.org/protocols/433.92/switch/kaku_old.html
Solange pilight-send -p <switch_protocol> .... nicht geht, dann wird es auch mit FHEM nicht funktionieren!
Das ist dann eher ein Problem von pilight! Ggf. mal dort im Forum nachfragen.
Risiko
Hallo zusammen,
eigentlich habe ich pilight un der 433Mhz Welt den Rücken gekehrt.
Das war mein Einsteig in die Welt von FHEM, inzwischen arbeite ich mehr mit mqtt.
Aber in meinem log fand ich nur folgende Einträge:
2019.11.02 10:21:22 3: pilight_connector: Unknown code PITEMP,alecto_wx500,210,temperature:14.1,humidity:84,battery:1, help me!
2019.11.02 10:21:22 3: pilight_connector: Unknown code PITEMP,alecto_wx500,210,temperature:14.1,humidity:84,battery:1, help me!
2019.11.02 10:21:54 3: pilight_connector: Unknown code PITEMP,alecto_wx500,210,temperature:14.1,humidity:84,battery:1, help me!
2019.11.02 10:21:55 3: pilight_connector: Unknown code PITEMP,alecto_wx500,210,temperature:14.1,humidity:84,battery:1, help me!
2019.11.02 10:23:00 3: pilight_connector: Unknown code PITEMP,teknihall,165,temperature:-63.2,humidity:8,battery:1, help me!
2019.11.02 10:23:01 3: pilight_connector: Unknown code PITEMP,teknihall,165,temperature:-63.2,humidity:8,battery:1, help me!
Ich empfange da wohl Werte einer fremden Wetterstation, oder sogar mehrerer. Ich könnte mir das natürlich zu Nütze machen und mir so die Außentemperatur anzeigen lassen. (aber ich weiss ja gar nicht wo die Stationen stehen)
Komisch finde ich die Temperaturen an sich an der einen Stelle 14.1 und an der anderen -63.2 ?
Hallo stratege-0815,
und was nun die Frage\Problem?
Die -63.2 stimmen natürlich nicht. Dein Empfänger empfängt da irgendwas + Rauschen, was von pilight falsch interpretiert wird.
Risiko.
Hallo, habe eine Frage
Ich habe im Garten einen 2. PI mit pilight am laufen um Steckdosen und Thermometer darüber zu steuern und zu Empfangen. Das funktioniert auch super (lokal)
In meinem Haupt PI habe ich ein zweites Pilight_ctrl definiert mit der IP des Servers im Garten.
Jetzt habe ich die selben Geräte vom Garten auch auf dem Hauptserver angelegt und dort als IODEV den Garten pilight_ctrl angegeben.
Wenn ich jetzt vom Haupt Fhem im Garten schalten will geht es nicht, aber wenn ich vom Garten Fhem schalte bekomme ich die Zustandsänderung auf dem Haupt Fhem angezeigt.
Wieso kann ich nicht vom Haupt Fhem auf dem Garten Fhem schalten???
Okay habe den "FEHLER" gefunden
Die Geräte müssen in Beiden Fhem Instanzen unterschiedliche Namen haben.
Hatte diese vorher in beiden Gleich genannt und es ging nicht.
Jetzt heißt die eine Funksteckdose im GartenFhem lichterkette und im HauptFhem Lichterkette
So geht es
Prima.
Du könntest auch in pilight ein AdHoc-Netzwerk einrichten und nur eine Pilight-Instanz in FHEM einbinden. Die einzelnen Pilight-Geräte "unterhalten" sich selbst. Sollte auch gehen.
Hab es aber selbst noch nicht gemacht\probiert.
Siehe auch https://manual.pilight.org/adhoc_network.html
Risiko
Hallo zusammen,
ich hab einen RasPi (RasPi2) mit pilight am Laufen an den ein 8-Relais Modul angeschlossen ist. Pro Relais ist ein GPIO definiert und wird in der config.json von pilight mit dem Protokoll relay angesprochen. In der WebGui von pilight lässt sich das jetzt auch wunderbar schalten.
Auf einem anderen RasPi (RasPi1) läuft meine FHEM Instanz mit einem definiertem pilight_ctrl und einer Verbindung zum pilight auf dem RasPi2 mit State connected.
Jetzt die Frage: Kann man nun die einzelnen GPIOs aus FHEM heraus über pilight_ctrl ansprechen und wie müsste ich dann die "Geräte" definieren?
Hab schon das ein oder andere probiert, aber hat leider bisher nicht gefruchtet - auch bin ich mir nicht sicher, ob das relay-Protokoll von pilight_ctrl momentan unterstützt wird und es überhaupt eine Chance gibt. Den einzigen Hinweis auf relay fand ich in diesem Beitrag - mit offenem Ausgang :) (https://forum.fhem.de/index.php/topic,34632.msg327608.html#msg327608)
Viele Grüße,
laurello
Hallo laurello,
das relay Protokoll wird nicht unterstüzt. Ich kann es hier https://manual.pilight.org/protocols/index.html auch nicht finden.
Es hat sich an dem Zustand von damals also nichts geändert.
Ich benötige neben der Zeit erstmal deutlich mehr Informationen.
Ist es eher mit einem Switch (on|off] pro GPIO vergleichbar?
Vielleicht könntest du erstmal mittels pilight-receive loggen, was beim Schalten über die GUI gesendet wird.
Interessant wäre auch deine config.json.
Risiko
Hallo Risiko,
erstmal danke für deine schnelle Reaktion.
Warum das relay Protokoll in der Doku nicht mit drin steht, hab ich mich auch schon gefragt, da es dazu sogar mal ein eigenes Wiki gab, dies wohl aber irgendwann in dem Fortgang der Versionen und Umzug der Webserver verloren gegangen ist - aber gut.
Wie du schon schreibst, ist es wie ein Switch zu verstehen - pro definiertem GPIO ein Schalter mit on|off (high|low am GPIO). Aufgrund der angelegten oder nicht angelegten Spannung am Pin, zieht das Relais entweder an oder eben nicht.
Mit pilight-receive zu loggen, habe ich probiert, aber wie ich schon befürchtet habe, kommt da nichts zum Vorschein. Ich denke, da hier nicht wirklich eine "message gefunkt" wird und der Vorgang ja ein "send" aus pilight ist, ist das receive Modul gar nicht beteiligt.
Was ich dir allerdings geben kann ist das userreading, daß ich an der pilight_ctrl in fhem als rcv_raw bekomme:
rcv_raw {"origin":"sender","protocol":"relay","message":{"gpio":29,"state":"off"},"repeat":1,"uuid":"0000-dc-a6-32-121f5a"}
Ich weiß nicht genau, ob dir obiges rvc_raw userreading hilft, hab mir aber zum Vergleich auch das userreading eines Temperaturfühlers, der an GPIO7 einer anderen pilight Instanz hängt mal angesehen:
rcv_raw {"message":{"gpio":7,"temperature":25.4,"humidity":49.9},"origin":"receiver","protocol":"dht22","uuid":"0000-b8-27-eb-5d1178"}
Das ist anders aufgebaut und gibt receiver als origin an, das obige Beispiel sender - das war mir als grosser Unterschied aufgefallen.
Meine config.json hab ich mit angehängt - meine Benamung ist noch "virtuell" - noch hängt nichts hinter den Relais, aber das wäre das Ziel ;)
Viele Grüße,
laurello
Hallo.
Na das sind doch schon mal nützliche Infos.
{"origin":"sender","protocol":"relay","message":{"gpio":29,"state":"off"}}
Damit wäre es möglich das Schalten aus der pilight-web-gui in FHEM mitzubekommen und einen Switch zu aktualisieren.
Jetzt fehlt noch der andere Weg. Könntest du mal versuchen mittels pilight-send einen Port zu schalten!? Dann würde mich mal der Syntax von pilight-send interessieren.
pilight-receive müsste das ({"origin":"sender","protocol":"relay","message":{"gpio":29,"state":"off"}}) aber auch anzeigen.
Vielleicht findet man\du ;) im pilight Forum noch was zum relay-Protokoll.
Risiko.
Hallo Risiko,
ich hab mir die Syntax zusammen gestellt:
- für On: pilight-send -p relay -g 29 -t
- für Off: pilight-send -p relay -g 29 -f
Laut "pilight-send -p relay --help" wäre dies dann vollständig und korrekt.
Ein Schalten eines Ports ist mir aber leider noch nicht gelungen, da ich immer die Meldung "no gpio-platform configured" bekomme. Ob dies ein bug ist oder ich weitere Optionen angeben müsste, kann ich nicht sagen. Meine Versuche dies mit der Option -C für das config file und Angabe der config.json mit Pfad abzustellen, sind derzeit noch erfolglos.
Der abermalige Versuch des "Aufzeichnens" des Befehls über pilight-receive fördert leider auch nichts zu Tage - bleibt einfach still die Ausgabe, egal welchen Web-Schalter ich drücke >:(
Hast du aus deinem Erfahrungsschatz noch eine Idee bzw. bringt dir die Info über die Syntax etwas? Ich versuche auf jeden Fall weiter und hoffe auf einen Geistesblitz - evtl. stell ich mich ja nur dumm an.
Viele Grüße,
laurello
Welche Version Pilight nutzt du? Und hast du in der config.json diesen Eintrag? "gpio-platform": "raspberrypi3" je nachdem welchen PI du hast natürlich anpassen im Anhang ein Screenshot von meiner config.json ich nutze Pilight zum Senden/Empfangen mit 433 Mhz
Version ist die v8.1.5 und in der config.json steht die Plattform mit drin - in meinem Fall ein raspberrypi4
config.json:
...
"gpio-platform": "raspberrypi4"
...
Deswegen versteh ich auch die Fehlermeldung "no gpio-platform configured" nicht. Dann wollte ich dies über die -C config file Option sicher stellen beim pilight-send Aufruf - aber da bringt er mir immer ein "invalid option" - kennt er irgendwie nicht. Auch --config mag er nicht - keine Chance
Syntax zum Schalten sollte pilight-send -p relay -g 5 -t wobei "5" durch die Wiring gpio nummer ersetzt wird die du nutzt.
Die melding mit der GPIO Plattform ist aber normal, da es laut Doku raspberrypi4 nicht als Definition gibt, Versuche alternativ Mal raspberrypi3.
Laut Forum mußt du die letzte wiringx Version installiert haben damit pilight mit dem raspberrypi4 funktioniert
https://forum.pilight.org/showthread.php?tid=3582
Hallo Tueftler1983,
über den Aufruf von pilight-send für relay sind wir uns also einig ;)
Mit der GPIO Plattform hatte ich zuvor schon experimentiert und hatte - weil ich wie du in die Doku geschaut habe - erst raspberrypi3 drin stehen. Mit dieser Konfiguration lassen sich die Ports nicht mal über die WebGUI schalten, weswegen ich etwas gesucht hatte und dann auf das undokumentierte raspberrypi4 stieß. Dies hat dann auch auf Anhieb geklappt.
Ich habe trotzdem nochmal auf raspberrypi3 umgestellt und mit pilight-send probiert: Gleiches Verhalten - er sagt immer noch "no gpio-platform configured".
Trotzdem habe ich auch noch wiringX installiert und abermals probiert, aber auch wiringX hat nichts weiter gebracht: Gleiches Verhalten - abermals "no gpio-platform configured" wenn pilight-send aufgerufen wird.
Den Fehler wirft er immer aus der /home/pilight/source/daemon-dev/libs/pilight/protocols/GPIO/relay.c #89 - ERROR: no gpio-platform configured
Leider kein Erfolg.
Viele Grüße,
laurello
Um evtl. noch etwas mehr Infos zu bekommen, hab ich den pilight-daemon mal im Vordergrund im Debug Modus gestartet und über WebGUI geschaltet:
Zitat
(/home/pilight/source/daemon-dev/daemon.c #1532) [Jul 04 07:01:59:254931] DEBUG: socket recv: {"action":"control","code":{"device":"Channel1","state":"on"}}
(/home/pilight/source/daemon-dev/libs/pilight/core/socket.c #395) [Jul 04 07:01:59:255746] DEBUG: socket write succeeded: {"origin":"update","type":4,"uuid":"0000-dc-a6-32-121f5a","devices":["Channel1"],"values":{"timestamp":1593846119,"state":"on"}}
(/home/pilight/source/daemon-dev/daemon.c #405) [Jul 04 07:01:59:255807] DEBUG: broadcasted: {"origin":"update","type":4,"uuid":"0000-dc-a6-32-121f5a","devices":["Channel1"],"values":{"timestamp":1593846119,"state":"on"}}
(/home/pilight/source/daemon-dev/libs/pilight/core/socket.c #395) [Jul 04 07:01:59:256002] DEBUG: socket write succeeded: {"origin":"sender","protocol":"relay","message":{"gpio":29,"state":"on"},"repeat":1,"uuid":"0000-dc-a6-32-121f5a"}
(/home/pilight/source/daemon-dev/daemon.c #496) [Jul 04 07:01:59:256047] DEBUG: broadcasted: {"origin":"sender","protocol":"relay","message":{"gpio":29,"state":"on"},"repeat":1,"uuid":"0000-dc-a6-32-121f5a"}
(/home/pilight/source/daemon-dev/libs/pilight/core/socket.c #577) [Jul 04 07:02:00:967642] INFO: new client, ip: 192.168.2.35, port: 37072
(/home/pilight/source/daemon-dev/libs/pilight/core/socket.c #578) [Jul 04 07:02:00:967716] DEBUG: client fd: 18
(/home/pilight/source/daemon-dev/libs/pilight/core/socket.c #605) [Jul 04 07:02:00:967765] DEBUG: client id: 3
(/home/pilight/source/daemon-dev/daemon.c #1186) [Jul 04 07:02:00:967860] DEBUG: socket recv: {"action":"identify","options":{"receiver":1},"media":"all"}
(/home/pilight/source/daemon-dev/libs/pilight/core/socket.c #395) [Jul 04 07:02:00:967999] DEBUG: socket write succeeded: {"status":"success"}
(/home/pilight/source/daemon-dev/daemon.c #2549) [Jul 04 07:02:01:246800] DEBUG: cpu: 0.142362%
(/home/pilight/source/daemon-dev/daemon.c #2588) [Jul 04 07:02:04:36696] INFO: Interrupt signal received. Please wait while pilight is shutting down
Soweit sieht das erstmal gut aus.
Meinen pilight-send Aufruf als zweiten Versuch hat den daemon nicht interessiert - da kommen keine Informationen bzw. irgendeine Meldung - scheint an ihm vorbei zu gehen.
OK. Mit den Infos kann ich nach meinem Urlaub (wird leider frühestens Ende Juli) mal versuchen eine Testversion mit relay-Protokoll zu erstellen.
Risiko.
Hallo Risiko,
das klingt doch vielversprechend - danke dafür!
Schönen Urlaub,
laurello
Hall laurello,
wie versprochen hier eine Testversion mit relay-Protokoll.
Den Switch musst du wie folgt definieren
define myrelay pilight_switch relay <gpio number> all
Das all muss ein!
Viel Spaß beim Testen.
Risiko.
Hallo Risiko,
Traumhaft!
Heruntergeladen, eingespielt, Modul neu geladen, schnell define durchführt und mit gespannter Erwartung auf das Klicken des Relais auf dem Board auf "ON" gedrückt - funktioniert einwandfrei und auf Anhieb.
Ich sage ganz herzlich Danke von meiner Seite - das bringt mich doch ein riesiges Stück weiter und näher an die Umsetzung - jetzt liegt's nur noch an mir, das Vorhaben fertig zu bekommen. :D
Meine "alten" anderen Funksteckdosen hab ich auch nochmal zum Test durchprobiert - funktionieren nach wie vor noch - also keine "Nebeneffekte"
Ich schau mir das noch weiter an und durch und probier noch weiter rum - dann meld ich mich nochmal abschließend - macht aber einen bombigen Eindruck.
laurello
Prima.
Habe die Änderungen gerade eingecheckt.
Hier nochmal abschließend wie versprochen meine Rückmeldung, aber top, daß du schon eingecheckt hast. Hab in allen Testszenarien keine Probleme oder Nebeneffekte gefunden.
Damit ist pilight auf einem Remote System meiner Ansicht nach eine sehr einfache Möglichkeit auch lokal am Remote System angeschlossene "Geräte" über GPIO zu schalten und mit wenig Aufwand in fhem zu integrieren.
Toll!
Danke nochmal,
laurello
Guten Tag zusammen,
ich habe auf meinem Raspberry Pi 2 Model B Pilight 8.1.5-165-ga38fa85d und FHEM 6.0.23243 installiert. Bisher lief die Anbindung über das FHEM Modul pilight problemlos, bis ich ein Update von Jessie auf Stretch durchgeführt habe. Ich kann nun meine Schalter (define KuecheTischDeckeLampe pilight_switch kaku_switch 17277950 3) nicht mehr über FHEM ein- bzw. ausschalten. Im FHEM Log wird keine Fehlermeldung angezeigt, sondern scheinbar alles korrekt übergeben, aber wahrscheinlich kommt keine Rückmeldung von pilight und der Schalter bleibt im entsprechenden Status.
FHEM Log:
2020.11.29 10:02:30 4: Connection accepted from WEB_127.0.0.1_35292
2020.11.29 10:02:30 5: POST /fhem?cmd.KuecheTischDeckeLampe=set%20KuecheTischDeckeLampe%20on&XHR=1&fw_id=455 HTTP/1.1
Host: localhost:8083
Origin: http://10.10.10.10
Accept-Encoding: gzip, deflate
Authorization: Basic cGk6MjBDb250cm9sP0hvbWUxOA==
Accept: */*
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
Referer: http://10.10.10.10/fhem?detail=KuecheTischDeckeLampe
Accept-Language: de-de
X-Requested-With: XMLHttpRequest
X-Forwarded-For: 10.10.1.100
X-Forwarded-Host: 10.10.10.10
X-Forwarded-Server: 127.0.1.1
Connection: Keep-Alive
Content-Length: 0
2020.11.29 10:02:30 4: WEB_127.0.0.1_35292 POST /fhem?cmd.KuecheTischDeckeLampe=set%20KuecheTischDeckeLampe%20on&XHR=1&fw_id=455; BUFLEN:0
2020.11.29 10:02:30 5: Cmd: >set KuecheTischDeckeLampe on<
2020.11.29 10:02:30 5: KuecheTischDeckeLampe(Set): on 1 of 1
2020.11.29 10:02:30 4: pilight(Write): RCV (pilight_switch) -> KuecheTischDeckeLampe,on
2020.11.29 10:02:30 4: pilight(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":17277950,"unit":3,"on":1}}
2020.11.29 10:02:30 5: pilight(SendNonBlocking): queue size 1
2020.11.29 10:02:30 4: BlockingCall (pilight_ctrl_Send): created child (5450), uses telnetPort to connect back
2020.11.29 10:02:30 4: WEB: /fhem?cmd.KuecheTischDeckeLampe=set%20KuecheTischDeckeLampe%20on&XHR=1&fw_id=455 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate
2020.11.29 10:02:30 4: Connection accepted from telnetPort_127.0.0.1_37242
2020.11.29 10:02:30 5: Cmd: >{BlockingRegisterTelnet($cl,1)}<
2020.11.29 10:02:30 5: pilight(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":17277950,"unit":3,"on":1}}
2020.11.29 10:02:30 4: pilight(Send): RCV ->
2020.11.29 10:02:30 5: Cmd: >{BlockingStart('1')}<
2020.11.29 10:02:30 5: Cmd: >{pilight_ctrl_SendDone('pilight|1')}<
2020.11.29 10:02:30 4: pilight(SendDone): message successfully send
[Nov 29 09:16:53:160421] INFO: new client, ip: 127.0.0.1, port: 41688
[Nov 29 09:16:53:160570] DEBUG: client fd: 24
[Nov 29 09:16:53:160644] DEBUG: client id: 4
[Nov 29 09:16:53:163577] DEBUG: socket recv: {"action":"send","code":{"protocol":["kaku_switch"],"id":17277950,"unit":3,"on":1}}
[Nov 29 09:16:53:163761] DEBUG: client disconnected, ip 127.0.0.1, port 41688
Über die Konsole zu schalten (pilight-send -p kaku_switch -i 17277950 -u 3 -t) funktioniert jedoch korrekt, und auch der geänderte Status des Schalters wird korrekt in FHEM angezeigt.
[Nov 29 09:15:06:331391] INFO: new client, ip: 10.10.10.10, port: 33140
[Nov 29 09:15:06:331517] DEBUG: client fd: 24
[Nov 29 09:15:06:331564] DEBUG: client id: 4
[Nov 29 09:15:06:331683] DEBUG: socket recv: {"action":"identify"}
[Nov 29 09:15:06:331927] DEBUG: socket write succeeded: {"status":"success"}
[Nov 29 09:15:06:332238] DEBUG: socket recv: {"action":"send","code":{"off":1,"unit":3,"id":17277950,"protocol":["kaku_switch"]}}
[Nov 29 09:15:06:332705] DEBUG: **** RAW CODE ****
[Nov 29 09:15:06:332772] DEBUG: socket write succeeded: {"status":"success"}
315 2835 315 315 315 1260 315 1260 315 315 315 315 315 1260 315 315 315 1260 315 315 315 1260 315 315 315 1260 315 315 315 1260 315 1260 315 315 315 1260 315 315 315 1260 315 315 315 1260 315 315 315 315 315 1260 315 1260 315 315 315 315 315 1260 315 315 315 1260 315 315 315 1260 315 1260 315 315 315 1260 315 315 315 1260 315 315 315 1260 315 315 315 1260 315 315 315 1260 315 315 315 1260 315 315 315 1260 315 315 315 1260 315 315 315 315 315 1260 315 315 315 1260 315 315 315 1260 315 315 315 1260 315 315 315 1260 315 1260 315 315 315 1260 315 315 315 10710
[Nov 29 09:15:06:332961] DEBUG: **** RAW CODE ****
[Nov 29 09:15:06:333055] DEBUG: client disconnected, ip 10.10.10.10, port 33140
[Nov 29 09:15:06:337430] DEBUG: socket write succeeded: {"origin":"sender","protocol":"arctech_switch","message":{"id":17277950,"unit":3,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-5fe98b"}
[Nov 29 09:15:06:337700] DEBUG: socket write succeeded: {"origin":"sender","protocol":"arctech_switch","message":{"id":17277950,"unit":3,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-5fe98b"}
[Nov 29 09:15:06:337790] DEBUG: broadcasted: {"origin":"sender","protocol":"arctech_switch","message":{"id":17277950,"unit":3,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-5fe98b"}
Scheinbar wird in pilight, wenn ich über FHEM schalte, nichts ausgegeben/an den Socken geschrieben?
Gab es dieses Problem bereits bzw. benötigt Ihr weitere Logs?
Schon einmal vielen Dank für die Hilfe und viele Grüße
raspberry
Hallo.
Aus dem Log kann ich nichts entnehmen. Setze doch das Loglevel von pilight_ctrl mind. auf 4 hoch.
Wieso verwendest du eine eigene und geänderte Version von pilight? Ich denke, der Fehler ist eher da zu suchen.
Risiko.
Vielen Dank für die schnelle Antwort!
Zitat von: Risiko am 29 November 2020, 10:24:58
Aus dem Log kann ich nichts entnehmen. Setze doch das Loglevel von pilight_ctrl mind. auf 4 hoch.
Log-Level von pilight ist bereits auf 6. Habe die Logs von "pilight-daemon -D". Oder muss ich etwas anderes umstellen bezüglich Log?
Zitat von: Risiko am 29 November 2020, 10:24:58Wieso verwendest du eine eigene und geänderte Version von pilight? Ich denke, der Fehler ist eher da zu suchen.
Ich habe zumindest bewusst keine eigene bzw. geänderte Version von pilight installiert, sondern ganz normal über apt-get installiert. Es handelt sich um die aktuelle stabile Version (deb http://apt.pilight.org/ stable main) Welche Version soll ich verwenden? Bzw. was soll ich anpassen?
Sieht mir mit "8.1.5-165-ga38fa85d" nicht so aus. Das ist keine stable Version!
Im Log steht, dass die Nachricht von FHEM raus ist.
Leider kann ich nicht mehr beitragen.
Zitat von: Risiko am 29 November 2020, 10:56:41
Sieht mir mit "8.1.5-165-ga38fa85d" nicht so aus. Das ist keine stable Version!
Im Log steht, dass die Nachricht von FHEM raus ist.
Leider kann ich nicht mehr beitragen.
Es handelte sich dabei doch um eine nightly Version, hatte die vor langer Zeit für einen Test installiert und wohl doch nicht mehr zurückgestellt. :-\
Mit der stabile Version 8.1.5 funktioniert alles nun korrekt!
Vielen Dank für die schnelle Rückmeldung und die tolle Unterstützung! Ganz herzlichen Dank für das FHEM Modul!
Hallo!
Prima Sache, die Anbindung von pilight!
Ich habe 2 pilight (Daemonen, jeweils mit mehreren Clients) an unterschiedlichen Standorten, die per VPN verbunden sind. Die beiden pilights laufen für sich jeweils autonom, ich wollte sie aber in EINEM fhem kontrollieren können.
Das erste pilight verbindet sich (pilight_ctrl) und ich kann Temp./Hum. Daten lesen und Schalter schalten.
Wenn ich aber das zweite pilight anlege (pilight_ctrl), dann ist und bleibt das disconnected.
2020.12.04 11:17:32 1: piliRemote: Can't connect to 192.168.1.17:5000: Connection timed out
Ich habe mich auch gefragt, wie bei MEHREREN pilights das FHEM wissen soll, mit welchem pilight es welche Geräte auskaspert, da eine Zurodnung zu einem pilight_ctrl ja nicht stattfindet.
Gibt es einen Möglichkeit, mehrere pilight Daemonen mit EINEM FHEM zu kontrollieren? :-)
PS: Ich sehe gerade, dass man das IODev definieren kann, und damit Geräte einem 2. pilight zuordnen könnte. Jetzt muss ich rausfinden, warum sich das 2. pilight nicht verbindet.
PPS: Die Firewall hat wie üblich dazwischengefunkt, jetzt sind beide pilights "connected"..
_____
Zusatzfrage: Das Protokoll "cpu_temp" kann das FHEM Modul nicht? Da funken ein paar Raspis rum und die würde ich gerne einbinden...
2. Frage: Bei den Temp/Hum Sensoren ändert sich bei mir bei jedem Batteriewechsel die ID. Muss man dann das Gerät in FHEM neu anlegen? Oder kann man die ID per Befehl ändern?
Hallo ich habe auch Zwei Pi's auf denen jeweils eine Pflicht Instanz läuft, beide eingebunden in einem Fhem.
Das läuft ohne Probleme. Die einzelnen Geräte wissen über das Attribut IOdevice über welchen Pilight sie kommunizieren.
Jupp, ich habe das ja auch mittlerweile hinbekommen, siehe PS und PPS :-)
Bleibt noch:
Zusatzfrage: Das Protokoll "cpu_temp" kann das FHEM Modul nicht? Da funken ein paar Raspis rum und die würde ich gerne einbinden...
2. Frage: Bei den Temp/Hum Sensoren ändert sich bei mir bei jedem Batteriewechsel die ID. Muss man dann das Gerät in FHEM neu anlegen? Oder kann man die ID per Befehl ändern?
Ist sicher kein spezifisches Problem, aber wie bekomme ich das Modul dazu, nicht 10 MB in einem halben Tag in's generelle Log von fhem zu schreiben. Das sprengt ja alle Maßstabe
....
2020.12.04 21:09:01 3: pili1(Parse): unknown protocol -> datetime
2020.12.04 21:09:02 3: pili2(Parse): unknown protocol -> datetime
2020.12.04 21:09:02 3: pili1: Unknown code PITEMP,cpu_temp,3,temperature:42.236, help me!
...
Verbose auf 1 oder 0?
Zitat von: Tueftler1983 am 04 Dezember 2020, 21:59:49
Verbose auf 1 oder 0?
Verbose 1 ist schon viel besser! Danke! :-)
Nächster Frage: Bei den Temp/Hum Sensoren ändert sich bei mir bei jedem Batteriewechsel die ID. Muss man dann das Gerät in FHEM neu anlegen? Oder kann man die ID per Befehl ändern?
Die kannst du in der Dev ändern.
Bei orange klicken und bei Rot ändern
Zitat von: claudio-fhem am 04 Dezember 2020, 21:17:24
Ist sicher kein spezifisches Problem, aber wie bekomme ich das Modul dazu, nicht 10 MB in einem halben Tag in's generelle Log von fhem zu schreiben. Das sprengt ja alle Maßstabe
....
2020.12.04 21:09:01 3: pili1(Parse): unknown protocol -> datetime
2020.12.04 21:09:02 3: pili2(Parse): unknown protocol -> datetime
2020.12.04 21:09:02 3: pili1: Unknown code PITEMP,cpu_temp,3,temperature:42.236, help me!
...
Beschreibung lesen http://fhem.de/commandref.html#pilight_ctrl ;)
Siehe ignoreProtocol
Risiko
Zitat von: claudio-fhem am 04 Dezember 2020, 23:16:46
Verbose 1 ist schon viel besser! Danke! :-)
Nächster Frage: Bei den Temp/Hum Sensoren ändert sich bei mir bei jedem Batteriewechsel die ID. Muss man dann das Gerät in FHEM neu anlegen? Oder kann man die ID per Befehl ändern?
...
Beschreibung lesen http://fhem.de/commandref.html#defmod ;)
Mittels defmod oder über die Oberfläche, so wie Tueftler1983 es beschrieben hat
Zitat von: claudio-fhem am 04 Dezember 2020, 14:10:13
Zusatzfrage: Das Protokoll "cpu_temp" kann das FHEM Modul nicht? Da funken ein paar Raspis rum und die würde ich gerne einbinden...
Doch kann es. Es fehlt nur ein entsprechendes pilight_temp Device.
Zitat von: Risiko am 05 Dezember 2020, 08:42:07
Doch kann es. Es fehlt nur ein entsprechendes pilight_temp Device.
Sehr gut, das werde ich nachholen!
Ich will die Temp/Hum. gerne graphisch darstellen, aber nicht alle paar Sekunden in's log schmieren, das ist ja inflationär. Ich hab bei FlieLog eine Lösung mit einer Dummy-Variablen und alle 5 sec und nur wenn sich was verändert, aber das ist ja fürchterliche kompliziert. Gibt's da eine einfache Lösung, alle 5 min einen Wert zu speichern? :-)
Zitat von: Risiko am 05 Dezember 2020, 08:42:07
Doch kann es. Es fehlt nur ein entsprechendes pilight_temp Device.
Hmm, also mit der UUID als "id" funzt das nicht... und die IDs der Raspis in der config.json von pilight sind meist 1 und 2, aber es gibt die alle mehrfach an den beiden Instanzen...
define CPU_pi1 pilight_temp cpu_temp 0000-b8-27-eb-asdfgh...zeigt nur "defined" als Status, selbst wenn ich das Device der korrekten IODev zuordne...
Was ist die korrekte ID für cpu_temp? :-)
OK, anders als bei den Temp/Hum. Sensoren ist die ID bei cpu_temp total arbiträr und wird einfach manuell in der config.json von pilight vergeben, damit kann man dann das Device bei fhem anmelden...
Ein Problem weniger.
Zitat von: claudio-fhem am 05 Dezember 2020, 12:38:55
Ich will die Temp/Hum. gerne graphisch darstellen, aber nicht alle paar Sekunden in's log schmieren, das ist ja inflationär. Ich hab bei FlieLog eine Lösung mit einer Dummy-Variablen und alle 5 sec und nur wenn sich was verändert, aber das ist ja fürchterliche kompliziert. Gibt's da eine einfache Lösung, alle 5 min einen Wert zu speichern? :-)
Lesen, lesen, lesen ;D
https://wiki.fhem.de/wiki/Event-on-change-reading