Hallo Zusammen,
gibt es für skripte die ich in 99myUtils schreibe, die Möglichkeit, diese zu debuggen?
Ich habe eine einfache If Abfrage und anhand des Ergebnisses weiß ich, dass er immer in den else Zweig geht.
Ich möchte meine Variablen sehen, die ich dem Skript übergebe. Ist das irgendwie möglich?
Hoffe ich bin als ABAP Entwickler nicht allzu sehr verwöhnt ;-)
Hi,
ich habe da eher wenig Ahnung, aber Du kannst alles ins Log schreiben.
So wie hier -> https://wiki.fhem.de/wiki/E-Mail_senden#Raspberry_Pi
Gruß Otto
Einen so tollen Debugger wie in ABAP gibt es für fhem nicht.
Für Perl selbst gibt es das schon.
LOG, oder LOG3...
Ist dein Freund
In 99_utils geht nur Log, weil du kein $hash hast
Selbstverständlich kannst Du debuggen. Ausserhalb und innerhalb von FHEM kannst du das mit print oder printf. Und nur innerhalb von FHEM geht das am einfachsten mit
Log 1, "Text";
ok, besser als nichts :P
danke euch!
Zitat von: CoolTux am 23 Dezember 2016, 16:23:40
Selbstverständlich kannst Du debuggen. Ausserhalb und innerhalb von FHEM kannst du das mit print oder printf. Und nur innerhalb von FHEM geht das am einfachsten mit
Log 1, "Text";
Das würde ich nicht als debuggen bezeichnen
Ausserhalb von fhem gibt es padre
Padre hat einen symbolischen Debugger integriert. Kommt an ABAP nicht heran.
Unter Eclipse gibt es auch Perl-plugins mit Debugger Unterstützung - kenne ich aber nicht.
Ich habe in Fhem mal Weekdaytimer stark umgebaut und habe mir unter Padre Fhem für Tests teilweise emuliert, hat ganz gut geklappt.
Mit Log wäre ich wohl wahnsinnig geworden. Bzw. Ich hätte den Umbau nicht angefangen.
Neue Funktionen erstelle ich meist ersteinmal mit padre und kopiere das getestete Ergebnis nach Fhem
Zitat von: Dietmar63 am 23 Dezember 2016, 16:23:22
In 99_utils geht nur Log, weil du kein $hash hast
Für Log3 brauche ich aber doch auch nicht zwingend einen hash:
Zitat von: rudolfkoenig am 18 August 2013, 16:39:25
- In allen Modulen sollte Log durch Log3 ersetzt werden: der einen zusaetzlichen ersten Parameter benoetigt: entweder $hash oder $name.
<...>
Log3 $name, 4, "Device $dev opened";
- Die 3 in Log3 steht fuer den Anzahl der Parameter (3 :).
- Falls man kein Geraet ($name/$hash) hat, dann kann man auch undef verwenden, dann wird es mit "global verbose" verglichen.
<...>
- Log funktioniert weiterhin, und wird durch "Log3 undef, ..." implementiert, sollte aber nur noch von fhem.pl oder Enduser verwendet werden.
Ich verwende für Ausgaben ins Log eigentlich immer Log3, egal von wo aus.
Btw.: Nicht verwechseln: 99_utils.pm und 99_myUtils.pm ;)
Zitat von: linus30 am 23 Dezember 2016, 16:07:56Hoffe ich bin als ABAP Entwickler nicht allzu sehr verwöhnt ;-)
...doch.
Wir können Rudi ja mal fragen, ob er /h implementieren kann.
SCNR,
Thorsten
Zitat von: Dietmar63 am 23 Dezember 2016, 16:45:26
... habe mir unter Padre Fhem für Tests teilweise emuliert...
Hi Dietmar,
könntest du das beschreiben, bzw. lässt sich das wie ein Projekt exportieren? Ich suche sowas schon lange. Habe schon mal mit Perl- Emulatoren experimentiert, was aber nie zufriedenstellend war. Jetzt werde ich mir Padre mal angucken.
Gruß und schönes Fest
Frank
Ich habe einfach alle Funktionen, die man für eine
Define xxx
beinötigt, in ein Modul zusammenkopiert und in einem TestModul per use verfügbar gemacht.
Dann habe ich die Define-Definition in eine Textkonstante geschrieben und durch einen Direktaufruf interpretieren lassen.
Dadurch kannst du für einen Großteil der Entwicklung den Padre Debugger verwenden.
Wenn bei der Definition dann timer entstehen, kannst du auch deren Abarbeitung erzwingen, indem du einfach deren Verarbeitungsroutine aufrufst. Man muss allerdings von Fall zu Fall unterscheiden, wie man dann vorgeht.
Ich suche die Sachen nachher mal zusammen und veröffentliche den Ansatz
habe ein fhemStd mit folgenden Funktionen angelegt:
dietmar@dietmarMedion:~/FhemSVN1/fhem/FHEM$ grep -nr sub ./fhemStd.pm
use strict;
use vars qw(%attr); # Attributes
use vars qw(%data); # Hash for user data
use vars qw(%defs); # FHEM device/button definitions
use vars qw(%intAt); # Internal at timer hash, global for benchmark
use vars qw(%modules);
use vars qw($readingFnAttributes);
#our(%attr); # Attributes
#our(%data); # Hash for user data
#our(%defs); # FHEM device/button definitions
#our(%intAt); # Internal at timer hash, global for benchmark
my $evalSpecials;
my $intAtCnt=0;
my $nextat=0; # Time when next timer will be triggered.
20:sub Log3($$$) {
30:sub Log($$){
35:sub trim($) {
42:sub SortNumber {
51:sub myInternalTimer($$$$$) {
68:sub myRemoveInternalTimer($$) {
80:sub myGetHashIndirekt ($$) {
90:sub InternalTimer($$$$) {
101:sub RemoveInternalTimer($) {
108:sub AttrVal($$$) {
114:sub EvalSpecials($%) {
137: # perform macro substitution
154:sub SemicolonEscape($){
164:sub ReadingsVal($$$){
175:sub TimeNow(){
178:sub FmtDateTime($){
182:sub FmtTime($){
187:sub AnalyzeCommandChain($$) {
189:sub readingsBeginUpdate($) {
191:sub readingsEndUpdate($$){
193:sub readingsBulkUpdate($$$@){
195:sub readingsSingleUpdate($$$$){
197:#sub sunrise_abs_dat($){
201:#sub sunset_abs_dat($){
und dann ein TestModul geschrieben:
package main;
use strict;
use POSIX;
use Data::Dumper;
$Data::Dumper::Sortkeys = 1;
use lib '.';
use fhemStd;
do "98_WeekdayTimer.pm";
do "98_Heating_Control.pm";
do "99_SUNRISE_EL.pm";
# define hc WeekdayTimer HeizungKueche de fr,$we|23:35|25 34|23:30|22 23:30|16 23:15|22 12|23:45|16
# define hc WeekdayTimer HeizungKueche de 20:35|25 34|14:30|22 21:30|16 21:15|22 12|23:00|16
# define hw WeekdayTimer HeizungKuech de mo-so,$we|{sunrise_abs_dat($date)}|18 mo-so,$we|{sunset_abs_dat($date)}|22 ;
# define ht WeekdayTimer HeizungKuech de mo-so,!$we|{sunrise_abs_dat($date)}|18 mo-so,!$we|{sunset_abs_dat($date)}|22 ;
# define hh WeekdayTimer HeizungKuech de {sunrise_abs_dat($date)}|19 {sunset_abs_dat($date)}|21 ;
# define hx WeekdayTimer HeizungKueche de 12 22:35|25 23:00|16
# define ha WeekdayTimer HeizungKueche de *{twilight("TL","sr","7:30:00","9:00:00")}|auf {twilight("TL","ss","17:00:00","21:00:00")}|zu
# define keller_heizteppich_timer WeekdayTimer keller_heizteppich 17:00|14400 21:00|14400 01:00|14400 05:00|7000 { fhem("set @ on-for-timer %") }
my $fht = { NAME => "heku", TYPE => "FHT", "desired-temp" => 16.0 };
$defs{"heku"} = $fht;
my $def = 'xx WeekdayTimer heku de 02:30|22 21:30|16 21:15|22 12|23:00|16';
$def = 'xx Heating_Control heku de $we 21:35|25 34|22:30|22 21:30|16 21:15|22 12|23:00|16';
$def = 'xx WeekdayTimer heku de $we {sunrise_abs_dat($date)}|12 {sunset_abs_dat($date)}|14';
$def = 'xx Heating_Control heku de !$we 05:35|25 06:15|22 06:50|19 12:00|25 12:30|22 14:00|19 15:30|20 18:15|22 19:00|16 (heizungAnAus("Ein")) ';
my $HASH = {};
$attr{$HASH->{NAME}}{verbose} = 5;
Heating_Control_Define($HASH, $def);
#print Dumper \%intAt;
#print Dumper $HASH->{profil};
print Dumper $HASH;
#join("\n", map { "$_:".length(Dumper \$defs{$_})) } sort keys %defs);
foreach my $timer (sort keys %intAt) {
my $fn = $intAt{$timer}{FN};
my $tim = $intAt{$timer}{TRIGGERTIME};
print "$fn $timer " . FmtTime($tim) . "\n";
#no strict "refs";
#my @ret = &{$fn} ($intAt{$timer}{ARG});
#use strict "refs";
}
Praktisch ist zum Beispiel:
use fhemStd;
do "98_WeekdayTimer.pm";
do "98_Heating_Control.pm";
do "99_SUNRISE_EL.pm";
Wenn das Testmodul im Original-FHEM Verzeichnis liegt, kannst du mit diesen Zeilen die Original-FHEM-Module weiterentwickeln/testen/verwenden, je nach dem was du brauchst.
Unter padre kannst du dann symbolisch debuggen
Vielen Dank! Das mit der Modulprogrammierung ist zwar noch zu hoch für mich, aber versuchen einzusteigen wollte ich immer schon mal. Vielleicht kann mir deine Testumgebung dabei das Verstehen erleichtern. DWIM Perl ist gerade frisch installiert... :)