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

[bgewehr]

Tja, es läuft EINMAL, danach kommt statt des Timestamps der Value() des Readings.

Jörg, kannst Du Dir das erklären?
'Fritzbox-Callmoncall_timestamp' ist der Name des basic.value aus dem Widget.
'FB_call_timestamp' ist der Name des gads im basic.value im Widget.

Code Auswählen Erweitern


[io.domotiga]: update item: FB_call_timestamp val: 2015-01-02 21:27:27
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["2015-01-02 21:27:27"]
io_domotiga.js:115 [io.domotiga] receiving data: {"cmd":"item","items":["FB_call_timestamp","call"]}
io_domotiga.js:121 [io.domotiga]: update item: FB_call_timestamp val: call
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["call"]
io_domotiga.js:115 [io.domotiga] receiving data: {"cmd":"item","items":["FB_call_timestamp","connect"]}
io_domotiga.js:121 [io.domotiga]: update item: FB_call_timestamp val: connect
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["connect"]
io_domotiga.js:115 [io.domotiga] receiving data: {"cmd":"item","items":["FB_call_timestamp","disconnect"]}
io_domotiga.js:121 [io.domotiga]: update item: FB_call_timestamp val: disconnect
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["disconnect"]


Ich behaupte, das hier läuft (ist aber was anderes):

Code Auswählen Erweitern


###############################################################################
#
# Read fhem device Reading timestamps (gadval == timestamp)
#
###############################################################################

sub ReadingsTimestamp(@)
{
  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 = main::ReadingsTimestamp($device, $reading, 0);
    $param->{cmd} = 'send';
  }
  if ($param->{cmd} eq 'send')
  {
    $param->{gad} = $gad;
$param->{gadval} = $event;
$param->{gads} = [];
    return undef;
  }
  elsif ($param->{cmd} eq 'rcv')
  {
    return 'done';
  }
  elsif ($param->{cmd} eq '?')
  {
    return 'usage: Readingstimestamp';
  }
  return undef;
}


[bgewehr]

Edit:
Ich vermute, dass es damit zu tun hat, dass das Reading von FBCallmonitor, das ich verwende "event" heißt und "event" womöglich fronthem in die Irre führt, kann das sein?


Widerlegt, weil bei anderen Readings das Gleiche passiert.

Tja, es läuft EINMAL, danach kommt statt des Timestamps der Value() des Readings.

Jörg, kannst Du Dir das erklären?
'Fritzbox-Callmoncall_timestamp' ist der Name des basic.value aus dem Widget.
'FB_call_timestamp' ist der Name des gads im basic.value im Widget.

Code Auswählen Erweitern


[io.domotiga]: update item: FB_call_timestamp val: 2015-01-02 21:27:27
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["2015-01-02 21:27:27"]
io_domotiga.js:115 [io.domotiga] receiving data: {"cmd":"item","items":["FB_call_timestamp","call"]}
io_domotiga.js:121 [io.domotiga]: update item: FB_call_timestamp val: call
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["call"]
io_domotiga.js:115 [io.domotiga] receiving data: {"cmd":"item","items":["FB_call_timestamp","connect"]}
io_domotiga.js:121 [io.domotiga]: update item: FB_call_timestamp val: connect
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["connect"]
io_domotiga.js:115 [io.domotiga] receiving data: {"cmd":"item","items":["FB_call_timestamp","disconnect"]}
io_domotiga.js:121 [io.domotiga]: update item: FB_call_timestamp val: disconnect
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["disconnect"]


[herrmannj]

will have a look soon 

[hyper2910]

Hi Jörg,

du hast doch auch die LED Bulbs, Modul WIFILight.

Bekommst du diese in SV angesteuert?

Im Log auf FHEM sehe ich nur!
PC: error TVLicht: converter syntax: missing paramter

Gruss Dirk

[herrmannj]

Hi Dirk,

selbstredend ! Gutes Modul 

Du musst drei die GADs nehmen, allen dreien den converter RGBCombined geben und daran, als parameter, die 3 GAD in der Reihenfolge R,G,B anhängen.  Der converter setzt die drei Einzelsignale von sv zusammen. Funktioniert perfekt.

Auf sv Seite bin ich fast zufrieden, ich nehme den shifter für das Lampensymbol (und Schalter) sowei einen slider. Ein wenig doof (finde ich) das ich nochmal einen RGB für die Farbe dahinter setzen muss, eigentlich hätte ich das gern als RGB-shifter.

Grundsätzlich hab ich das auch mal kurz getestet - die svg icons könnte man per fill mit der Lampenfarbe innen ausfüllen - ich hab es aber noch nicht verstanden wie der Syntax lautet um dem shifter mit svg icons zu betreiben. Dann könnte man schnell ein widget klöppeln. Allerdings habe ich das auch nur kurz getestet weil, bin ja mehr mit fronthem beschäftigt.

Wenn jemand weiß wie der syntax für svg icons im shifter lautet bitte gern posten.

vg
Jörg

[herrmannj]

Tja, es läuft EINMAL, danach kommt statt des Timestamps der Value() des Readings.

Jörg, kannst Du Dir das erklären?

yes, I see:

der converter kennt 3 (main) modes (($param->{cmd} eq 'get'))
get: sv fragt aktiv das GAD an,
send: fhem schickt den Wert pro-aktiv an sv
rcv: sv sendet an fhem.

Du hast unter 'get"

Code Auswählen Erweitern

$event = main::ReadingsTimestamp($device, $reading, 0);
wenn sv den Wert aktiv anfragt (einmal: pageload) wird der timestamp genommen.
Der Zweig drunter wird aktiv wenn fronthem das event (aus fhem) sieht, da wird bei Dir jetzt das event (hier reading) durch-gereicht.

So gehts:

Code Auswählen Erweitern


  if ($param->{cmd} eq 'get')
  {
    $param->{cmd} = 'send';
  }
  if ($param->{cmd} eq 'send')
  {
    $param->{gad} = $gad;
    $param->{gadval} = main::ReadingsTimestamp($device, $reading, 0);
    $param->{gads} = [];
    return undef;
  }


Zweig 'get':
Unterscheidung zwischen 'fronthem holt den Wert" und 'fronthem bekommt den Wert' hier nicht möglich, timestamp muss immer geholt werden. Daher gleich mode auf 'send' ändern damit der nächste Zweig immer genommen wird.
Zweig 'send'
$param->{gadval} (der geht an sv raus) mit dem timestamp laden.

Bei 'rcv'
return 'done': perfekt, dann kommt fronthem nicht auf dumme Ideen falls jemand auf dem GAD was aus sv zurückschickt.

$param->{cmd} eq '?'
Da soll später mal eine online Hilfe zurückgegeben werden die dann im converter eingeblendet werden kann, so wie bei excel die hints zur Benutzung einer speziellen Funktion.

vg
Jörg

[bgewehr]

yes, I see:

der converter kennt 3 (main) modes (($param->{cmd} eq 'get'))
get: sv fragt aktiv das GAD an,
send: fhem schickt den Wert pro-aktiv an sv
rcv: sv sendet an fhem.

Zweig 'get':
Unterscheidung zwischen 'fronthem holt den Wert" und 'fronthem bekommt den Wert' hier nicht möglich, timestamp muss immer geholt werden. Daher gleich mode auf 'send' ändern damit der nächste Zweig immer genommen wird.
Zweig 'send'
$param->{gadval} (der geht an sv raus) mit dem timestamp laden.

Warum dann nicht bei Direct genauso?

Code Auswählen Erweitern


if ($param->{cmd} eq 'get')
  {
    $param->{cmd} = 'send';
  }
  if ($param->{cmd} eq 'send')
  {
    $param->{gad} = $gad;
$param->{gadval} = ($reading eq 'state')?main::Value($device):main::ReadingsVal($device, $reading, '');
$param->{gads} = [];
    return undef;
  }


Das hat bei mir einen Fehler behoben, den ich schon länger hatte: dass nämlich Texte mit Leerzeichen bei get anders erschienen sind als bei send. Bei get waren sie immer vollständig, bei send waren sie immer nur bis zum ersten Leerzeichen enthalten.
Nach der Änderung oben scheint das behoben zu sein.

[bgewehr]

Hi Dirk,

selbstredend ! Gutes Modul 

Jörg, kannst Du mal den SV-Code für dieses Layout posten? Dein Raum gefällt mir sehr gut!

[herrmannj]

Hi @all,

ich versuche jetzt seid gestern Abend ein encoding Problem zu lösen, langsam gehen mir die Ideen aus:

Problem: Umlaute werden in smartVISU falsch dargestellt.
Nachstellen:
fhem: dummy erstellen, dann set den dummy 'Ö'
sv:  basic.value
dann über "Direct" mit dem dummy verbinden.

Darstellung in sv als "Ö"

Das ist die korrekte (byte) Repräsentation  in UTF-8.

Der Weg fronthem -> sv geht über perl -> JSON (UTF8) -> ws (UTF8) -> JSON (UTF8) -> jquery mobile in sv.

Ich habe jetzt testweise überall mal convert (UTF8 ...) reingesetzt, bringt natürlich alles nix.
Den browser hab ich "hart" auf UTF8 gestellt (nix), nginx "gezwungen" UTF8 coding zu für die page zu verwenden (nix), meta im head in allen Spielarten ... (guess what: nix) ... jetzt gehen mitr irgendwie die Ideen aus.

Hat jemand weitere Ideen oder gar die Lösung ?

vg
jörg

[herrmannj]

Jörg, kannst Du mal den SV-Code für dieses Layout posten? Dein Raum gefällt mir sehr gut!

sehr gern. Für den slider hängt noch ein user css dran dami der blöde val weg ist. vg

[herrmannj]

Warum dann nicht bei Direct genauso?
...
Das hat bei mir einen Fehler behoben, den ich schon länger hatte: dass nämlich Texte mit Leerzeichen bei get anders erschienen sind als bei send. Bei get waren sie immer vollständig, bei send waren sie immer nur bis zum ersten Leerzeichen enthalten.
Nach der Änderung oben scheint das behoben zu sein.

geht beides. Ist eher so ein logik Ding. Bei send werden die ja frei Haus geliefert und man kann sich das extra "holen" sparen. Von der performance ist es aber vmtl egal. Damian macht das bei DOIF sogar konsequent nur über readingsval und nimmt das event nur als Anlass im modul aktiv zu werden.

Der aktuelle Weg hat den Vorteil a: einen call (readingsval) zu sparen und b: auch 'flüchtige' events (ohne reading) zu bekommen. Ich muss wohl eher das abschneiden am space reparieren, aber bis dahin kannst Du das gern genauso fixen.

vg
Jörg

[bgewehr]

Für den slider hängt noch ein user css dran dami der blöde val weg ist. vg

Du kannst auf ein separates css verzichten:

Code Auswählen Erweitern


<td rowspan="3" align="left" class="pos">
{{ basic.slider(id~'pos', gad_pos, min, max, step, 'vertical') }}
</td>


Die class "pos" zeigt nur den slider, die class "ui-slider-input" zeigt nur den VAL und - logisch, class="pos:ui-slider-input" zeigt beides!

[hyper2910]

@Jörg,

kannst du mir mal einen kompletten Block zu einem RGB Device posten.

Irgendwie hakt es noch!

[Jojo11]

Hallo,

ich habe nochmal ein feedback zur Stabilität:
- FHEM läuft mit SV auf cubietruck.
- SV installiert und zwei devices eingerichtet (PC und handy).
- Beide laufen und sind mit SV verbunden (state "connected").
- Zwischendurch (während einer Kaffeepause) schmiert fhem ab und der cubie startet neu (watchdog installiert).
- Beide Systeme laufen wieder, aber weder vom handy (state " ? ? ? ") noch vom PC (state "disconnected") lässt sich eine Verbindung herstellen (rote Ecke oben rechts).
- Ein schließen/neu-öffnen der browser-tabs bringt nichts.

Was dabei ein wenig kritisch ist sind die spontanen FHEM-Abstürze. Leider findet sich im FHEM log nichts dazu. Kann ich dazu im Nachhinein noch irgendwo etwas finden?
Wie kann ich beides wieder miteinander verbinden? Ich hab erstmal nichts erneut neu gestartet, um evtl. noch Hinweise zum Absturz finden zu können.

schöne Grüße
Jo

[herrmannj]

@Jörg,

kannst du mir mal einen kompletten Block zu einem RGB Device posten.

Irgendwie hakt es noch!

Hi,

poste mal bitte wie Du das widget in sv erstellt hast und bitte alle drei GAD cfgs aus dem Editor.

Achte bitte darauf das Du die id auf der sv Seite nicht ausversehen doppelt vergeben hast (innerhalb der Seite)

vg
jörg