Anleitung: Anbindung an FHEM zum Umschalten zwischen internem und externem Klingeln

  • Hi,


    in diesem Thema ging es unter anderem darum, vom DoorPi eine Handynummer anstatt eines internen Telefons anzurufen. Weiterhin wurde kurz beschrieben, wie man zwischen intern und extern umschalten kann.


    Ich habe das jetzt noch ein wenig weiter verfolgt und die Umschaltung in mein FHEM eingebunden. Hier die Anleitung dazu:


    Im DoorPi drei Tasten mit Actions belegen:
    Taste1: Nummer aus Datei anrufen
    Taste2: interne Nummer in Datei schreiben
    Taste3: externe Nummer in Datei schreiben


    Zum Beispiel so:


    Code
    1. [EVENT_OnKeyUp_0]
    2. 10 = file_call_value:/usr/local/etc/DoorPi/tools/call.txt
    3. [EVENT_OnKeyUp_1]
    4. 10 = os_execute:echo **701 > /usr/local/etc/DoorPi/tools/call.txt
    5. [EVENT_OnKeyUp_2]
    6. 10 = os_execute:echo 0172xxxxxxx > /usr/local/etc/DoorPi/tools/call.txt


    Dann in FHEM einen dummy anlegen, der den Wert "internal" und "external" haben kann.

    Code
    1. define doorBellTarget dummy


    Dann ein notify, welches auf Änderungen des dummys reagiert:

    Code
    1. define onDoorBellTarget notify doorBellTarget:.* { onDoorBellTargetState($EVENT) }


    Und letztendlich den Inhalt der Funktion, der per HttpUtils am Webinterface von DoorPi je nach Wert eine der beiden Tasten auslöst, die die Nummern in die Datei schreiben. Diese kommt in FHEM in die Datei 99_myUtils.pm:



    Die URL ist entsprechend die eigenen Gegebenheiten anzupassen (User/Password/IP/Port/Key etc..)


    Dann habe ich mir noch zwei schicke Buttons für die Visualisierung gemacht, und schon kann ich per Tastendruck umschalten. Sieht dann so aus:
    [Blockierte Grafik: http://www.bernd-schubart.de/downloads/doorpi/fhem_klingelmodus.png]

  • Kennst Du smartvisu? Das benutze ich als Visualisierung. Die Buttons sind einfach vom Typ basic.button, und das Item ist der doorBellTarget dummy in FHEM. Der eine Button setzt den state auf internal und der andere auf external.

    Kenne ich, nutze ich aber nicht. Aber jetzt wirds mir klar, hatte gedacht das ist ein einzelner Button den du mit Eventstate Icons jeweils wechseln lässt. :)

  • Hätte dazu mal eine generelle Verständnisfrage: Nach längerer Zeit habe ich mir wieder mal dem Thema gewidmet und auf meinem Raspi das neue DietPi installiert. Mit der vorzüglichen Anleitung konnte ich DoorPi problemlos installieren und der Dienst sowie die Weboberfläche funktionieren.
    Meine Anforderung: Zwei Klingeltaster, welche zwei verschiedene SIP-Rufnummern über die Fritzbox anrufen sollen. Am besten sollten auch Parallelrufe funktionieren (Postbote drückt beide Taster gleichzeitig). Video und Audio, sowie Türöffner brauche ich nicht. Also ganz einfache Funktion.


    Mir ist jedoch nicht ganz klar, wie ich jetzt die Zuordnung der GPIO Kontakte zu den Rufnummern herstellen kann. Welche Config muss ich dafür nehmen? In der Weboberfläche kann man das leider nicht einstellen, das wäre dann eine runde Sache.


    Vielleicht hat jemand für mich den finalen Tipp, damit ich das Projekt vollenden kann...? :)

  • @baerberry


    Du kannst das schon in der WebOberfläche eingeben.
    Dazu musst aber die Parameter von Hand eingeben.


    Geht auch per config datei mit


    sudo nano /usr/local/etc/DoorPi/conf/doorpi.ini


    Hab mich auch gerade ein Wenig mit der Knotig gespielt.
    Wenn du die GPIOs noch frei hast die ich verwende, kannst du folgende Knotig Probieren:



    Ob das aber mit dem Anruf Gleichheit klappt kann ich dir nicht sagen.
    Du musst halt noch die SIP Einstellungen vornehmen und die Fritzbox konfigurieren.
    Die Internen Rufnummer musst du auch noch anpassen.


    Gruß Robert

  • Wenn ich das richtig Verstanden habe, könnte ich auch FHEM dazu nutzen um Sonnenauf- und Sonnenuntergang auf DoorPi zu bekommen?


    Gruß Robert


    Korrekt, dazu gibt es folgendes Modul:


    Zitat von FHEM WIKI

    Das Hilfsmodul SUNRISE_EL bietet Funktionen, um Aktionen abhängig von Sonnenauf- und -untergangszeiten durchzuführen.


    http://www.fhemwiki.de/wiki/SUNRISE_EL


    welche Events du via HTTP Request dann bei DoorPi steuerst, bleibt Dir überlassen.

  • Sicher, du kannst aus FHEM heraus einen beliebigen Tastendruck an DoorPi schicken.


    In der Anleitung oben habe ich übrigens "echte" Tasten vom PiFace verwendet, mittlerweile habe ich das umgestellt auf das virtuelle Keyboard. Somit hat man beliebig viele Tasten.


    Wenn du in die Richtung Sonnenaufgang/Sonnenuntergang was machst, stell das mal hier rein ;) Ich bin auch interessiert dran, ich möchte die Beleuchtung von meinem Namensfeld damit steuern ohne einen zusätzlichen Sensor zu verbauen.


    edit: Überschnitten mit dem Post von irqnet :D


    noch ein edit: Ich habe in meinem FHEM das twilight Modul am Laufen, das scheint mir auch dafür geeignet.

  • Joker: Du hast Recht, twilight ist glaube ich die aktuellere Fassung.


    Ich stelle mir die Konfig relativ simpel vor, anhand der Geokoordinaten +x Stunden/Minuten den http request auf ein Event im Doorpi schicken. Das Namensfeld sollte sich ja mit einer einfachen LED beleuchten lassen, also muss dafür nur ein GPIO oder wer hat einen PiFace Ausgang schalten.


    Wird bei mir auch so gemacht, ist aber noch nicht umgesetzt :)



    Habe gerade mal ein Objekt in FHEM definiert:


    define Tageslicht twilight 0.00000 0.0000


    was dann folgende readings liefert:


    azimuth198.6825.04.2016 14:19
    compasspointsouth25.04.2016 14:19
    condition025.04.2016 14:04
    elevation51.9125.04.2016 14:19
    horizon025.04.2016 14:04
    light625.04.2016 14:04
    nextEventss_weather25.04.2016 14:04
    nextEventTime20:43:0125.04.2016 14:04
    sr06:20:4525.04.2016 14:04
    sr_astro03:53:5025.04.2016 14:04
    sr_civil05:37:4825.04.2016 14:04
    sr_indoor06:20:4525.04.2016 14:04
    sr_naut04:50:2425.04.2016 14:04
    sr_weather06:20:4525.04.2016 14:04
    ss20:43:0125.04.2016 14:04
    ss_astro23:10:0325.04.2016 14:04
    ss_civil21:26:0125.04.2016 14:04
    ss_indoor20:43:0125.04.2016 14:04
    ss_naut22:13:2625.04.2016 14:04
    ss_weather20:43:0125.04.2016 14:04
    state625.04.2016 14:04
    twilight10025.04.2016 14:19
    twilight_weather10025.04.2016 14:19


    light definiert den aktuellen Zustand


    0Völlige Dunkelheit; relativer Sonnenstand zum Horizont: -18°
    1astronomische Dämmerung; relativer Sonnenstand zum Horizont: zwischen -12° und -18°
    2nautische Dämmerung; relativer Sonnenstand zum Horizont: zwischen -6° und -12°
    3bürgerliche Dämmerung; relativer Sonnenstand zum Horizont: zwischen 0° und -6°
    4"indoor"-Dämmerung; Sonnenstand zwischen indoor_horizon (sofern der Wert ungleich Null ist) und 0°
    5"Wetter"-Dämmerung; Sonnenstand zwischen indoor_horizon und einem virtuellen Wetter-Horizont (abhängig von der Angabe einer Weather_position)
    6"normales" Tageslicht


    Der Zustand müsste dann über einen Watchdog abgefragt und das Event getriggert werden:


    define Daemmerung_Watchdog DOIF ([Tageslicht:light] eq "6") (GetFileFromURL(http://doorpi/event) DOELSEIF ([Tageslicht:light] ne "6") (GetFileFromURL(http://doorpi/event)



    edit: scheint zu klappen, ich lasse mir gerade zum testen aus FHEM eine Nachricht über Telegram schicken wenn sich der Status ändert, aktuell ist er bei 9 was sich nicht mit der Tabelle deckt, weil light nicht gleich state ist. Hier die Erklärung:


    STATE wird beim Twilight-Modul von 0 - 11 durchgezählt.
    0 -> vor astronomischen Aufgang
    1 -> vor nautischem Aufgang
    2 -> vor zivilem Aufgang
    3 -> vor Sonnenaufgan
    4 -> vor Indoor-Aufgang
    5 -> vor "Wetter-Aufgang"
    6 -> vor "Wetter-Untergang" (also den meisten Tag lang)


    Bis hierher ist light = STATE. Von nun an wird light wieder weniger (es wird ja dunkler) aber STATE schreitet vor, um Sonnenuntergänge von -aufgängen unterscheidbar zu machen.


    7 -> vor Indoor-Untergang
    8 -> vor Sonnenuntergang
    9 -> vor zivilem Untergang
    10 -> vor nautischem Untergang
    11 -> vor astronomischem Untergang


    Bitte auch bedenken, dass in der Nordhälfte Deutschlands die Sonne astronomisch im Sommer ca. 6 Wochen lang nicht untergeht, State wird also nicht alle Werte durchlaufen und light wird nie 0 sein.


    Der Einfachheit sollte man also das Reading light abfragen und nicht den Status, habe das mal oben ergänzt.

  • Ich hab so was (zum Beispiel) für die Rolladensteuerung mit sunset und sunrise am laufen.

    Code
    1. define at_Rolladen_auf at *{sunrise(-60)} { \
    2. fhem 'set ez_rolladen_links off';;\
    3. fhem 'set ez_rolladen_rechts off';;\
    4. fhem 'set wz_rolladen_links off';;\
    5. fhem 'set wz_rolladen_rechts off';;\
    6. fhem 'set wz_rolladen_balkon off';;\
    7. }
    8. attr at_Rolladen_auf room Rolladen

    Ist nicht aufwändig, nicht so genau, aber für meine Ansprüche bei den Rolladen passt das....
    Twilight läuft bei mir auch, ist aber um einiges aufwändiger ^^

  • Meine rolladensteurung ist ein wenig komplizierter. Aber von Prinzip her würde das reichen.
    Man könnte auch einfach mit zwei notify arbeiten.


    Bin heute nicht dazu gekommen, mir ist mal wieder mein raspi dhcp und bind abgeraucht. Man sollte halt einfach nicht so viel an wichtigen System rumspielen. Ach und oft genug ein Backup ziehen!!!!

  • Meine rolladensteurung ist ein wenig komplizierter. Aber von Prinzip her würde das reichen.
    Man könnte auch einfach mit zwei notify arbeiten.


    Bin heute nicht dazu gekommen, mir ist mal wieder mein raspi dhcp und bind abgeraucht. Man sollte halt einfach nicht so viel an wichtigen System rumspielen. Ach und oft genug ein Backup ziehen!!!!

    Ja, das habe ich auch ziemlich leidvoll feststellen müssen. Einmal unbedacht einen Befehl abgesetzt, dann war die Arbeit an fhem von 3 Monaten futsch. Seitdem läuft ein cronjob, der täglich die fhem.cfg wegsichert....