Wunschlliste Themen

[Wzut]

Ich möchte nicht wissen, in wie vielen Modulen es selbstgebastelte Temperaturlisten gibt.
----snipp ----
Gibt es 10_MAX irgendwo

a. das werden einige sein, in 38_BEOK habe ich damals auch ne eigene gebaut und IMHO sind alle ein kleines Stück andres da die Hardware i.d.R. eben ihren eigenen min/max Bereich hat.

b. natürlich , seit vielen Jahren im svn : 10_MAX.pm

[Beta-User]

Da gibt es vermutlich in der Tat einige (weekprofile würde mir einfallen, das aber on/off wieder anders löst).

Es gibt auch teilweise einen generischen Ansatz: die FHEMWEB-widgets. Die sind aber afaik in Javascript realisiert und nur für FHEMWEB interessant (wie vermutlich das hier  auch). Was bei "selectnumbers" fehlt, wäre die option, weitere Elemente zu ergänzen (und deren Position in der Liste zu bestimmen), neben on/off noch "day", "night", "open", "half", "close"...

Also z.B. so:

Code: [Auswählen]

attr <device> setList temperature:selectnumbersplus,4.5,0.5,30.5,lin:1,off:0,on:2,day,nightZiffern hinter den Doppelpunkten für optionale Positionsangaben in der Dropdown-Liste, was nicht dezidiert angegeben ist, wird einfach unten angefügt...

[Beta-User]

Anderes Problem:

Wie bekommt man mehrstufige Module mit GPUtils exportiert, so dass die "Initialize"-Funktion auch gefunden wird?

Konkret: die MySensors-Modulfamilie besteht u.a. aus den Packages MYSENSORS und MYSENSORS::DEVICE. "MYSENSORS" ist kein Problem, aber versuche ich den Export bei bei MYSENSORS::DEVICE, wird die Funktion nicht gefunden... Habe dann erst mal ein "FHEM::" vor den Package-Namen plaziert und dann versucht, das ganze über einen wrapper zu lösen. Klappt beides nicht auf die Schnelle.
Vielleicht hat ja einer eine Idee, ohne dass ich da weiter  allzuviel  Zeit reinstecke? Aktuelle Modulfassung mit dem Wrapper-Versuch im Anhang.

[Christoph Morrison]

b. natürlich , seit vielen Jahren im svn : 10_MAX.pm

Ich meinte deine Entwicklerversion, bevor sie final im SVN landet.

[RichardCZ]

Anderes Problem:

Wie bekommt man mehrstufige Module mit GPUtils exportiert, so dass die "Initialize"-Funktion auch gefunden wird?

Konkret: die MySensors-Modulfamilie besteht u.a. aus den Packages MYSENSORS und MYSENSORS::DEVICE. "MYSENSORS" ist kein Problem, aber versuche ich den Export bei bei MYSENSORS::DEVICE, wird die Funktion nicht gefunden... Habe dann erst mal ein "FHEM::" vor den Package-Namen plaziert und dann versucht, das ganze über einen wrapper zu lösen. Klappt beides nicht auf die Schnelle.
Vielleicht hat ja einer eine Idee, ohne dass ich da weiter  allzuviel  Zeit reinstecke? Aktuelle Modulfassung mit dem Wrapper-Versuch im Anhang.

GP_Export macht aus MYSENSORS::DEVICE::Init ein main::DEVICE_Init

[Beta-User]

GP_Export macht aus MYSENSORS::DEVICE::Init ein main::DEVICE_Init

Das hatte ich schon vermutet. Die eigentliche Frage hinter der Frage war: Wie löst man das am besten auf? Ich sehe folgende Varianten:
- "leave as was" - Initialize bleibt weiter außerhalb des Packages (Bronzezeit oder so...?).
- Package-Struktur der Modulfamilie wird geändert, dieser Teil wird MYSENSORS_DEVICE. Das kommt mir aber kontraproduktiv zu der "angedachten" allgemeinen Modularisierung vor.
- GPUtils-Export wird angepaßt, dass es fhem.pl (?) was "passendes" unterschiebt (z.B. abgeleitet v. Dateinamen statt aus dem letzten Teil des Packages).
- fhem.pl (?) wird geändert, dass es bei "gepackage-ten" Modulen von sich aus "Initialize" sucht (=Verzicht auf Export). Dann müßte jemand Rudi einen patch vorschlagen, der das kann... (Das wäre eigentlich m.E. die "richtige" Lösung ).

[RichardCZ]

Die eigentliche Frage hinter der Frage war: Wie löst man das am besten auf?

Ich glaube, die eigentliche Frage ist: Was willste haben? 
Wenn Du das mal kohärent darstellen kannst, kann ich Code anbieten.

[Beta-User]

Ich glaube, die eigentliche Frage ist: Was willste haben? 
Wenn Du das mal kohärent darstellen kannst, kann ich Code anbieten.

Mir ist es im Prinzip egal. Ich kann das auch auf "as was" belassen (bzw. dahin zurückdrehen) und mit Perlcritic-Gemaule an der Stelle leben .

Die anderen Varianten waren eher zur allgemeinen Diskussion gedacht, was der "richtige Weg" ist. Wenn ich das nach meinem Bauchgefühl entscheiden müßte, würde ich mir in fhem.pl eine zentrale Erweiterung von CommandReload() wünschen, die die ganze Exportiererei überflüssig macht (ab https://svn.fhem.de/trac/browser/trunk/fhem/fhem.pl#L2587; das scheint intern von mehreren Stellen her aufgerufen zu werden, v.a. beim auch beim Start). Streng nach dem Motto: Wenn es in dem Package eine "Initialize" (oder von mit aus: "FHEM_Initialize")-Funktion gibt, dann führe die aus, wenn das Modul genutzt wird (via define)...

Alternativ müßte man GPUtils dahingehend "aufschlauen", dass "FHEM::" als Präfix generell verworfen wird (relevant für AutoShuttersControl und evtl. andere) und alle anderen Bestandteile mit einem "_" verbunden werden statt des "::"? Das macht aber nur Sinn, wenn die "Teil-Modul-Benennungsstruktur" ok ist, die MySensors da an der Stelle grade praktizieren.
Auch das kann ich nicht wirklich beantworten. Ich würde dazu neigen, da bei 00_MYSENSORS und 10_MYSENSORS_DEVICE evtl. noch ein FHEM:: davorzusetzen; diese Module arbeiten nur mit FHEM zusammen, die anderen beiden Bauteile (Message.pm/Constants.pm) könnten auch woanders (außerhalb FHEM in der allgemeinen Perl-Welt) genutzt werden... (k.A., ob sie das tun; vermute: nein).

[RichardCZ]

GP ist ein wenig "matschig". Es macht in diesem Fall überhaupt keinen Unterschied ob man selbst custom-mäßig im Namespace rumfuhrwerkt oder das GP überlässt.
Da GP ohnehin eingeschränkt ist, kann man das auch selbst machen.

Du willst MYSENSORS::DEVICE::Init -> main::MYSENSORS_DEVICE_Init ?

Dann mach doch

*{'main::MYSENSORS_DEVICE_Init'} = *{'Init'};

in MYSENSORS::DEVICE. Das ist auch schon egal. 

oder

Code: [Auswählen]

#!/usr/bin/perl
# For Emacs: -*- mode:cperl; mode:folding -*-

use warnings;
use strict;
use v5.28.1;

package main;

MYSENSORS_DEVICE_Init();


package MYSENSORS::DEVICE;

sub main::MYSENSORS_DEVICE_Init { goto &Init }

sub Init {
    say "Blah";
    return;
}
das sollte "Blah" ausgeben. Das ist sogar etwas sauberer als GP. Aber noch ne Weile und ich entdecke meine Vorliebe für Schlammbäder.

[RichardCZ]

Weil ich's "grad sehe":

https://svn.fhem.de/trac/changeset/22270/trunk/fhem/FHEM/98_JsonList2.pm?old=21509&old_path=trunk%2Ffhem%2FFHEM%2F98_JsonList2.pm

Siehe oben in diesem Thread diverse quoting Geschichten.

Code: [Auswählen]

$ret .= "{ \"Value\":\"".JsonList2_Escape($v->{VAL})."\",";
$ret .=   " \"Time\":\"".JsonList2_Escape($v->{TIME})."\" }";

=>

$ret .= q|{ "Value":"| . JsonList2_Escape($v->{VAL})  . q|",|
      . q| "Time":"|   . JsonList2_Escape($v->{TIME}) . q|" }|;
Und wenn man sich die Sache so scharf anschaut, fragt man sich warum JsonList2_Escape nicht gleich die umliegenden Anführungszeichen setzt, denn das wird bei jedem Aufruf (mühsam - mit angelehnten Zahnstochern) im aufrufenden Code gemacht.

In einem Paralleluniversum würde also der Code so aussehen:

Code: [Auswählen]

sub JsonList2_Escape {
  my $foo = shift // return q{"null"};

  $foo =~ s/([\x00-\x09\x0b-\x1f\x5c])/sprintf '\u%04x', ord($1)/ge; # Forum 57377
  $foo =~ s/"/\\"/g;
  $foo =~ s/\n/\\n/g;

  my $bar = "x$foo";

  return utf8::decode($bar) ? qq{"$foo"} : q{"<BINARY>"}; # Forum #55318
}
und dann

Code: [Auswählen]

$ret .= '{ "Value":' . JsonList2_Escape($v->{VAL})  . ','
      . ' "Time":'   . JsonList2_Escape($v->{TIME}) . ' }';