erste beta - fronthem, smartVISU (closed, Bitte die Anschlussthreads benutzen)

[avg123-de]

Hast Du in fhem schon mal eventmap 500:On 1000:Off probiert? Natürlich mit NumDirect Converter!

Hallo bgewehr,

habe ich probiert, jedoch mit eventMap on:500 off:1000. 
Jedoch wird mir in sv immer 500 (also on) angezeigt, egal wie er in FHEM steht.

viele Grüße
Alexander

[herrmannj]

@Jörg: mir sind drei Fälle begegnet, in denen ich
1.) ein Reading setzen wollte, für das es kein Set gibt -> setreading()
2.) ein Attribut gefragt war und kein Reading -> AttrVal() setattr()
3.) ich wollte den Timestamp eines Readings haben, nicht den Wert -> ReadingsTimestamp()

Ist sowas über spezielle Converter möglich?

Ein Glück das Du fragst. Nächtelang hab ich mir im Vorweg über das wie bei den convertern Gedanken gemacht - und jetzt sah es eine Woche so aus als ob wir das gar nicht brauchen 

#3, no prob
#2, yes, aber etwas mit Einschränkung weil attrib keine Events erzeugen. Du bekommst also keine Echtzeitaktualisierung in sv. Für disable und co geht es weil Rudi dankenswerter Weise Events dafür eingebaut hat. Wenn Du das echt als Schalter verwenden möchtest macht es Sinn den modulautor zu überzeugen das er ein set und ein reading einbaut - das hat aber nichts mit den convertern zu tun sondern ist systemisch.
#1, yepp, wobei ich mich da unwohl fühle - ist eigentlich so gar kein fhem-style. Du hast Dir was gedacht, gibt es einen anderen Weg das zu erreichen ?

vg
Jörg

[bgewehr]

Ich habe mir grade den AttributeDisplay Converter selbst gemacht, das war einfach.
Ein Attribut zu setzen, geht aber gar nicht, weil der set Befehl nicht im Converter steckt, sondern fest codiert ist.

Ich würde vorschlagen das Wort set im Converter festzulegen, dann kann man auch andere Möglichkeiten schaffen, ohne dass das gleich sehr schwierig wird. Man kann dann statt set auch setreading, setattribute und was auch immer nehmen! Ist das für Dich vorstellbar?

[bgewehr]

habe ich probiert, jedoch mit eventMap on:500 off:1000. 
Jedoch wird mir in sv immer 500 (also on) angezeigt, egal wie er in FHEM steht.

Ist klar, weil der Trick nur in eine Richtung funktioniert.

Du hast mehrere Möglichkeiten:
1) Du nimmst das Reading im fronthemDevice Editor raus. Dann kannst Du den Wert zwar setzen, wirst aber in SV nicht am switch über den Status benachrichtigt. Pack noch ein basic.value() daneben, dann weißt Du, wie der Schalter stehen sollte. Er schaltet dann aber sicher richtig.
2) Anstelle neuer Converter können wir auch converting widgets erstellen. Stell Dir einen basic.switch() in SV vor, der SVValueON, SVValueOff, FHEMValueON, FHEMValueOFF als Parameter hat, dann brauchen wir gar keine neuen Converter für sowas und machen das einfach in Widgets... Ist recht einfach zu erstellen, versuche Dich mal dran!

[bgewehr]

Ich würde vorschlagen das Wort set im Converter festzulegen, dann kann man auch andere Möglichkeiten schaffen, ohne dass das gleich sehr schwierig wird. Man kann dann statt set auch setreading, setattribute und was auch immer nehmen! Ist das für Dich vorstellbar?

Dumm, dann müsste auch der Editor das berücksichtigen und anstelle der Readings und set commands die attributes anbieten, um es ganz perfekt zu machen... oder man lässt das einfach so und sagt: ist die Expertenvariante, also brauchen wir keine Werthilfe.

[herrmannj]

Ich habe mir grade den AttributeDisplay Converter selbst gemacht, das war einfach.
Ein Attribut zu setzen, geht aber gar nicht, weil der set Befehl nicht im Converter steckt, sondern fest codiert ist.

Ich würde vorschlagen das Wort set im Converter festzulegen, dann kann man auch andere Möglichkeiten schaffen, ohne dass das gleich sehr schwierig wird. Man kann dann statt set auch setreading, setattribute und was auch immer nehmen! Ist das für Dich vorstellbar?

yepp, jenau. Bekommst halt keine Aktualisierung und das kann später (bei data-ajax=true) zum Problem werden weil es dann auch den initialen call nicht gibt. Aber, wie gesagt, dem converter isses egal.

Das mit dem "set" ist eingeplant. Wenn der  converter den job selber erledigt einfach 'done' zurückgeben (bsp #243 in fhconverter). Dann weiß das framework das der converter das erledigt hat und legt sich wieder schlafen. Für Dich bedeutet das bereits im converter das attribut auf das device zu setzen (das device bekommt der converter über den hash) und dann 'done' als return.

vg
jörg

[bgewehr]

Hier mein AttributeDirect Converter:

Code Auswählen Erweitern


###############################################################################
#
# Read and write fhem device Attributes (gadval == attribute == setval)
#
###############################################################################

sub Attribute(@)
{
  my ($param) = @_;
  my $cmd = $param->{cmd};
  my $gad = $param->{gad};
  my $gadval = $param->{gadval};

  my $device = $param->{device};
  my $attribute = $param->{reading};
  my $event = $param->{event};
 
  my @args = @{$param->{args}};
  my $cache = $param->{cache};

  if ($param->{cmd} eq 'get')
  {
    $event = main::AttrVal($device, $attribute, '');
    $param->{cmd} = 'send';
  }
  if ($param->{cmd} eq 'send')
  {
    $param->{gad} = $gad;
$param->{gadval} = $event;
$param->{gads} = [];
    return undef;
  }
  elsif ($param->{cmd} eq 'rcv')
  {
$param->{result} = $gadval;
$param->{results} = [];
    return undef;
  }
  elsif ($param->{cmd} eq '?')
  {
    return 'usage: Direct';
  }
  return undef;
}


[herrmannj]

Dumm, dann müsste auch der Editor das berücksichtigen und anstelle der Readings und set commands die attributes anbieten, um es ganz perfekt zu machen... oder man lässt das einfach so und sagt: ist die Expertenvariante, also brauchen wir keine Werthilfe.

ah ne, der plan ist anders. Da nur readings (und global) events erzeugen kann man (sofern irgendwie sinnvoll) ein anderes reading (oder event) als trigger nehmen. Ob und wie hängt natürlich dann von der ganz konkreten Situation ab.

Das attrib würde ich in diesem Fall dem converter als param geben, dann kann er getriggert werden (fhem->sv) und weiß was zu tun ist wenn sv sich meldet (param + val auf dem device xyz setzen)...

vg
jörg 

[herrmannj]

... beim setzen des attrib im converter musst Du noch auf den namespace achten. Alles was fhem ist beginnt dann mit main:: ...

tante edith:
jetzt hat haben sich die posts überschnitten, gerade gesehen das den namespace schon kennst. perfekt. Setzen geht, wie geschrieben, direkt im converter

[bgewehr]

so:

Code Auswählen Erweitern


  elsif ($param->{cmd} eq 'rcv')
  {
$param->{result} = $gadval;
$param->{results} = [];
$result = main::fhem('attr '.$device.' '.$attribute.' '.$gadval)
    return done;
  }

oder anders?

[herrmannj]

so:

Code Auswählen Erweitern


  elsif ($param->{cmd} eq 'rcv')
  {
$param->{result} = $gadval;
$param->{results} = [];
$result = main::fhem('attr '.$device.' '.$attribute.' '.$gadval)
    return done;
  }

oder anders?

fast:
return 'done';

Das ganze "rundherum" brauchst Du an der Stelle nicht mehr, main::fhem('attr' .... müsste eigentlich reichen.

addon:
und wie gesagt, ich würde den namen des attr in die params nehmen, und ein reading behalten was sich möglichst oft aktualisiert. Dann bekommt sv wenigstens verzögert mit das sich das attr verändert.

[herrmannj]

Ist klar, weil der Trick nur in eine Richtung funktioniert.

Du hast mehrere Möglichkeiten:
1) Du nimmst das Reading im fronthemDevice Editor raus. Dann kannst Du den Wert zwar setzen, wirst aber in SV nicht am switch über den Status benachrichtigt. Pack noch ein basic.value() daneben, dann weißt Du, wie der Schalter stehen sollte. Er schaltet dann aber sicher richtig.
2) Anstelle neuer Converter können wir auch converting widgets erstellen. Stell Dir einen basic.switch() in SV vor, der SVValueON, SVValueOff, FHEMValueON, FHEMValueOFF als Parameter hat, dann brauchen wir gar keine neuen Converter für sowas und machen das einfach in Widgets... Ist recht einfach zu erstellen, versuche Dich mal dran!

Hier wäre doch der "ich-mappe-dir-alles-converter" über den wir gesprochen hatten eigentlich das mittel der Wahl - oder ?
params on:500, off:1000 und fertsch. Oder sehe ich da was nicht.

vg
jörg

[bgewehr]

@Jörg: genau!

[herrmannj]

na dann machen wir das einfach .

Ich versuche mal zeitnah zu prüfen ob das laden von convertern aus der 99 so hinhaut wie ich möchte. Wenn ja ein Beispiel ins wiki und dann hat man was schnelles zur Selbsthilfe an der Hand.

Wenn man hier die 500 und 1000 hart kodiert (also nicht param) nehmen würde könnte man den in 12 sekunden aus dem OnOff ableiten.

vg
jörg

[herrmannj]

ich behaupte nicht das der hier läuft - aber das er nahe dran ist 

Code Auswählen Erweitern

sub special(@)
{
  my ($param) = @_;
  my $cmd = $param->{cmd};
  my $gad = $param->{gad};
  my $gadval = $param->{gadval};

  my $device = $param->{device};
  my $reading = $param->{reading};
  my $event = $param->{event};
 
  my @args = @{$param->{args}};
  my $cache = $param->{cache};

  if ($param->{cmd} eq 'get')
  {
    $event = ($reading eq 'state')?main::Value($device):main::ReadingsVal($device, $reading, 'on');
    $param->{cmd} = 'send';
  }
  if ($param->{cmd} eq 'send')
  {
    $param->{gad} = $gad;
$param->{gadval} = (lc($event) eq 'on')?'500':'1000';
$param->{gads} = [];
    return undef;
  }
  elsif ($param->{cmd} eq 'rcv')
  {
$param->{result} = ($gadval == 500)?'on':'off';
$param->{results} = [];
    return undef;
  }
  elsif ($param->{cmd} eq '?')
  {
    return 'usage: OnOff';
  }
  return undef;
}