Callmonitor für Anfänger

[Brockmann]

Mal eine Frage noch am Rande:wie programmiert ihr eigentlich in Perl? Ich meine ich versuche das so gut es geht im Notepad++, kopiere das Ganze dann nach fhem in dessen Editor und hoffe dass es läuft. Ziemlich mühsam das Vorgehen.

Mir reicht meist das hier:
http://www.fhemwiki.de/wiki/Konfiguration#Syntaxhervorhebung

Aber wenn es richtig komplex wird, benutze ich auch auch schon mal Notepad++ via Cut&Paste.

[Roaster]

Das habe ich auch bereits eingeschaltet, aber das "Programmieren" im Notepad++ ist ja mehr ein Try and Error.
Ich kann mir nicht vorstellen dass es da nichts anderes gibt um vernünftig in Perl zu programmieren und zu debuggen.

[Puschel74]

Hallo,

Ich mach alles in Notepad++ , wenn es nur ein paar Zeilen sind wandern die direkt über die Befehlszeile in die Konfig sonst wird eine eigene pm daraus.

Warum sollte es try&error sein?
Die Befehle sind immer die selben - die Werte sind immer die selben - die Geräte sind immer die selben - FHEM ist immer das selbe.
Irgendwann mal sollten die Befehle sitzen und wenn nicht kann man immer noch auf vorhandenen Code zurück greifen und diesen abändern.

Grüße

P.S.: Den Code von Elektrolurch habe ich gestern abend mal in meine Konfig kopiert (ohne Notepad++) und klappt einwandfrei.

[Roaster]

Nene, fhem und die Geräte sind immer dasselbe - die Anforderung was und wie etwas gesteuert, geloggt, die Daten beschafft werden und so weiter, per Perl wohl gemerkt, ist immer was anderes. Ich meine man sieht es ja bereits, dass man den Code für den Callmonitor auch anders schreiben kann im Vergleich zur Erstfassung. Ein paar Zeilen sind vielleicht identisch, aber der Rest schon nicht mehr.

Deshalb, und vor allem für Neulinge in Sachen fhem und Perl, ist es erst Mal Try&Error und das ist ganz schön mühselig, den Code Offline zu schreiben, zu kopieren und hoffen, dass fhem alles syntaktisch akzeptiert. Und dann weiß man noch nicht Mal, ob man nicht doch logische Fehler drin hat, die man irgendwie beseitigen möchte.

Michael

[Puschel74]

Hallo,

"Neulinge" sollten auch auf bereits vorhandene Module zurückgreifen und werden kaum solche oder ähnliche Programme schreiben.
Und wenn doch würde ich nichtmehr Neuling sagen.

Grüße

PS.: Ich benutze für neue Codes auch eine Testumgebung.

[Roaster]

PS.: Ich benutze für neue Codes auch eine Testumgebung.

Ha! - auf das Stichwort habe ich gewartet 

Jetzt wird's zwar OT aber ich frage jetzt doch nochmals nach: Du hast einen weiteren Raspberry Pi als Testserver und darauf schreibst du dein Coding? Aber auch hier gibt es jetzt wohl keine direkte Möglichkeit den Code, ich sage Mal, im Browser oder am Raspberry zu debuggen, oder?

Also, Code im Editor schreiben, ins fhem rüberkopieren und mit Log Einträgen oder Javascript Alerts (auch möglich?) sich einen Überblick über korrekt ausgeführten Code zu schaffen.

Michael

[fiedel]

Perl debuggen:

http://www.perlboard.de/perlguide/Kap12.html
http://www.thomas-fahle.de/talks/Einfuehrung_Perl_Debugger.pdf
http://de.perlmaven.com/debuggen-von-perl-skripten

Aber mir reicht auch notepad++ (Sprache "Perl" einstellen! / es gibt sogar eine Sprachregel für FHEM)
und das Kommando "Log 1" zum ausgeben von Variablen usw. ins normale FHEM- Log.

Gruß

Frank

[Puschel74]

Hallo,

Du hast einen weiteren Raspberry Pi als Testserver und darauf schreibst du dein Coding?

So ist es - wobei anfangs auch die FritzBox genügt hat.
Aber irgendwann ist für ein Modul ein Paket zu installieren und das wird dann recht mühsam (bis unmöglich).
Daher ein weiterer RasPi.

Aber auch hier gibt es jetzt wohl keine direkte Möglichkeit den Code, ich sage Mal, im Browser oder am Raspberry zu debuggen, oder?

Debuggen wirst du den Code wohl nur können wenn du ihn in einer passenden Umgebung laufen lässt.
Sprich - du brauchst mindestens Perl.
Und das hast du ja auf einem RasPi mit FHEM 

Sonst, wie fiedel schon geschrieben hat:

Aber mir reicht auch notepad++ (Sprache "Perl" einstellen! / es gibt sogar eine Sprachregel für FHEM)
und das Kommando "Log 1" zum ausgeben von Variablen usw. ins normale FHEM- Log.

Grüße

[Brockmann]

Jetzt wird's zwar OT aber ich frage jetzt doch nochmals nach: Du hast einen weiteren Raspberry Pi als Testserver und darauf schreibst du dein Coding? Aber auch hier gibt es jetzt wohl keine direkte Möglichkeit den Code, ich sage Mal, im Browser oder am Raspberry zu debuggen, oder?

Es muss nicht mal unbedingt Extra-Hardware sein. Man kann sich auch einen RaspberryPi als Virtuelle Maschine am PC aufsetzen und seinen echten Raspi da quasi reinklonen. Hat natürlich seine Grenzen, wenn es um den Zugriff auf Hardware wie CUL & Co. geht. Aber das wäre bei einem "echten" Zweit-Raspi ja nicht anders.

[Roaster]

Wenn man jetzt noch die Hardware des physischen Raspberry in der virtuellen Umgebung mit nutzen könnte, dann wäre es perfekt  So etwas wie USB über LAN, mal laut gedacht...

Ha! so etwas beispielsweise http://store.raspberrypi.com/projects/virtualhere.

Any device you plug into your Raspberry PI USB ports becomes directly accessable on a Windows/OSX/Linux machine over the network.

The Raspberry Pi USB ports become a direct extension of your desktop USB port

Schon Mal jemand daran gedacht und eventuell getestet?

Michael

[Roaster]

Servus Elektrolurch,

gibt es möglicherweise schon etwas Neues im Bezug auf den Refresh der readingsGroup bei ankommenden und ausgehenden Anrufen?

Grüße,
Michael

[Elektrolurch]

Hallo Roaster,

ja, es gibt etwas Neues:
Meiner Meinung nach tut readingsBulkUpdate nicht das, was es soll. Es aktualisiert zwar die readings, aber nicht den Screen, wenn es mehrmals hintereinander aufgerufen wird.

Folgendes habe ich nämlich gemacht:
Den CallMonitor nun zu einem eigenen Modul gemacht. Symbole für eingehende, ausgehende, verpasste Anrufe usw. sind nun über Attribute einstellbar und noch ein paar Sachen mehr.
Dabei können nun eingehnde Anrufe auch schon angezeigt werden, wenn es klingelt.
Da ich aber erst nach dem disconnect wweiß, wie lange der Anruf gedauert hat, muss ich dann in der angezeigten Tabelle den Anruf suchen, um die Anrufdauer nachträglich dort zu aktualisieren. Das mache ich, da ja nur ein Wert, mit readingsSingleUpdate - und siehe da, das klappte nämlich, die Anzeige wurde ohne Drücken von F5 aktualisiert.
Das hat mich auf die Idee gebracht, das Verschieben der Zeilen bei einem neuen Anruf und die Ausgabe der ersten Zeile mal anders zu programmieren:

Bisher war das so aufgebaut:

readingsBeginUpdate($hash);
# Die Schleife zum shiften der Inhalte
for(my $i..
{
readingsBulkUpdate($hash,..,1)
}
readingsEndUpdate($hash,1);

Obwohl da ja update auf 1 gesetzt wird, wird die Anzeige nicht aktualisiert.

Nun neu:
For(my $i...
{
readingsSingleUpdate($hash,..,1)
}

d.h. kein readingsBeginUpdate und readingsEndUpdate.
Und siehe da, nun wird die Anzeige korrekt aktualisiert.

Schaut man nun in die fhem.pl rein, sieht man, dass readingsSingleUpdate nichts anderes als drei Aufrufe sind:

readingsBeginUpdate
readingsBulkUpdate
readingsEndupdate

Für mich folgt daraus, dass die "Sammlung" von "Aktualisierungsereignissen" von readings irgendwo in der fhem.pl oder in der readingsGroup nicht korrekt abgearbeitet wird.

Da das Verschieben der Zeilen und Zellen  zu 30 Aufrufen von readingsSingleUpdate nun führt, wird dadurch ein ziemlicher Rechenoverhead produziert, aber nur so funktioniert es derzeit, dass die Anzeige direkt aktualisiert wird, ohne F5 drücken zu müssen.

Andre (Autor der readingsGroup) hatte zwar angeboten, sich das Mal anzusehen, er hat aber keine Fritzbox um das nachzustellen. Ich müsste also erst einmal ein Codebeispiel bauen, damit er sich das Verhalten der readingsGroup bei mehrfachem Aufruf von readingsBulkUpdate mal ansehen kann.

Mein Modul (TM = TelefonMonitor) läuft, muss aber noch ein paar Sachen testen. Jedenfalls dürfte die Anwendung von Nicht-Programmierern einfacher sein. Außerdem kann man nun beliebge viele Instanzen von Anruflisten (z.B. nur eingehende und eine zweite für alle Anrufe) erzeugen.
Außerdem kann man auch noch per Attribut Namen von perl-Routinen hinterlegen, die beim Ereignis ring und disconnect aufgerufen werden können.
(z.B. Signalisierung von Anrufen für Schwerhörige, durch Einschalten einer Lampe)

Gruß

Elektrolurch

[Roaster]

Hey Danke für die Antwort!

Kann das neue Modul auch noch oder wieder die anderen Ereignisse wie in_notconnected oder out_notconnected, damit ich entsprechende Icons zuweisen kann?

Edit: was mir mit dem alten Modul noch aufgefallen ist: aktuelle Anrufe/aktuell geführte Telefonate führen trotz F5 nicht zu einer Aufnahme in der readingsGroup. Ich gehe Mal davon aus, dass dies erst dann geschieht, wenn das Telefonat beendet ist.

Kann man dies auch abändern, so dass diese Ereignisse ebenfalls prompt angezeigt werden. Ziel ist ja, zumindest bei mir, dass man am Tablet an der Wand umgehend über ankommende Anrufe informiert wird, damit man entscheiden kann den Anruf anzunehmen oder nicht.

Michael

[coolice]

Hallo,

nachdem mein fhem jetzt auf einen Raspberry umgezogen ist (auf der Fritte hatte es ja keine Zukunft)
zieht sich der Callmonitor das Telefonbuch aus der Fritzbox nicht mehr.

Ist reverse-search-phonebook-file
./log/Fritz_Box_Telefonbuch.xml richtig oder ist der Pfad falsch (Davon gehe ich jetzt mal aus)

Mirco

[Markus Bloch]

Das Telefonbuch musst du nun von der FritzBox Web Oberfläche exportieren. Die XML Datei die du dabei erhälst musst du dann auf deinem Raspberry ablegen und den Pfad zu dieser Datei im Attribut reverse-search-phonebook-file eintragen.

Gruß
Markus