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

[bgewehr]

Zum Forum und der Nutzung langer Threads:

Ich rufe mir häufiger mal die Druckansicht auf und suche dann mit [Strg]+[F], das geht über alle Seiten...

[bgewehr]

Darum habe ich Folgendes gemacht:

1. aus dem Domotiga-Treiber einen FHEM-Treiber gemacht

Super, läuft bei mir ohne Probleme!

Kannst Du das im fhemwiki verewigen?

Ich habe mal das debian Paket yui-compressor benutzt und die .min.js Variante erstellt, ist auch wirklich nicht schwierig und auch für die von mir permanent veränderte widgets.js wichtig gewesen. Kannst Du beide Files im Wiki anbieten?

Vielen Dank!

[herrmannj]

Kannst Du die Architektur aus Deinem Kopf hier mal kurz rauslassen?


Gesendet von iPhone mit Tapatalk

yepp. Im coverter Teil (namespave fronthem) kommt de Struktur als hash an (sv -> fhem).

Im main:: muss dann ein Hash liegen wo die Zeiten schon geordnet sind. Jedes mal wenn über das frontend ein update kommt muss die Struktur neu aufgebaut werden und die uszu muss die Liste von unten nach oben durchgehen um den nächsten "Schaltzeitpunkt" zu finden. Wenn der feststeht muss ein Timer gesetzt werden (evtl bestehende Löschen). Wenn der timer feuert wird dann im Modul die Aktion ausgelöst (Event und / oder direktes Schalten eines konfigurierten device). Danach reload des Timers (also Struktur / hash durchlaufen, finden, Timer setzen)

Dazu kommt die Verwaltung von disable/enable (per attrib) sowie das formatieren und anziegen der Liste in fhem (per get?).
Hier dann auch der Rückweg von fhem -> sv via converter.

Außerdem muss die Struktur serialisiert werden und auf (fhem) Platte gespeichert damit die Termine, Zeiten nach einem fhem shutdown wieder geladen werden können. mMn wird das nicht über die fhem.cfg gehen können (weil sehr umfangreiche Datensätze im Vergleich zu den üblichen Attributen), daher braucht es eine  eigene cfg pro uzsu.

vg
jörg

[herrmannj]

Super, läuft bei mir ohne Probleme!

Kannst Du das im fhemwiki verewigen?

Ich habe mal das debian Paket yui-compressor benutzt und die .min.js Variante erstellt, ist auch wirklich nicht schwierig und auch für die von mir permanent veränderte widgets.js wichtig gewesen. Kannst Du beide Files im Wiki anbieten?

Vielen Dank!

Schau Dir mal in sv die make.php an - da steckt das minify drin. Man muss nur die Dateien händisch ergänzen und dann make.php aufrufen.

[bgewehr]

yepp. Im coverter Teil (namespave fronthem) kommt de Struktur als hash an (sv -> fhem).

Im main:: muss dann ein Hash liegen wo die Zeiten schon geordnet sind. Jedes mal wenn über das frontend ein update kommt muss die Struktur neu aufgebaut werden und die uszu muss die Liste von unten nach oben durchgehen um den nächsten "Schaltzeitpunkt" zu finden. Wenn der feststeht muss ein Timer gesetzt werden (evtl bestehende Löschen). Wenn der timer feuert wird dann im Modul die Aktion ausgelöst (Event und / oder direktes Schalten eines konfigurierten device). Danach reload des Timers (also Struktur / hash durchlaufen, finden, Timer setzen)

Dazu kommt die Verwaltung von disable/enable (per attrib) sowie das formatieren und anziegen der Liste in fhem (per get?).
Hier dann auch der Rückweg von fhem -> sv via converter.

Außerdem muss die Struktur serialisiert werden und auf (fhem) Platte gespeichert damit die Termine, Zeiten nach einem fhem shutdown wieder geladen werden können. mMn wird das nicht über die fhem.cfg gehen können (weil sehr umfangreiche Datensätze im Vergleich zu den üblichen Attributen), daher braucht es eine  eigene cfg pro uzsu.

Du gehst von EINEM zentralen UZSU device in FHEM aus, richtig?

Ich hatte bisher immer gedacht, EIN UZSU READING an das fhem device zu setzen, das ich schalten möchte und EIN ZENTRALES UZSU notify, das auf die uzsu-Readings aller devices reagiert und die entspr. at-Befehle erzeugt oder modifiziert.

Was meinst Du dazu? Zu simpel gedacht?

Alle Zeiten wären im normalen statefile gesichert, keine komplexe Sache, oder?

[HCS]

Das aber bitte nur als Vorschlag, wenn Du andere Ideen hast gerne rin damit 

Noch habe ich keinerlei Idee. Habe mich mit dem Thema noch gar nicht befasst.
Ich werde das mal auf mich wirken lassen und generell überlegen, wie das mit dem Treiber Stück für Stück vorwärts gehen kann.

[HCS]

Kannst Du das im fhemwiki verewigen?

Leider nicht. Habe keine wiki-Rechte.

Ich habe mal das debian Paket yui-compressor benutzt und die .min.js Variante erstellt, ist auch wirklich nicht schwierig und auch für die von mir permanent veränderte widgets.js wichtig gewesen. Kannst Du beide Files im Wiki anbieten?

Sinnvollerweise werde ich in Zukunft beide Varianten bereitstellen.
Wiki siehe oben.

Könnten wir nicht im "herrmannj/fronthem" repository auch den Treiber und evtl. allgemeingültige widgets in der jeweils aktuellen Version bereitstellen?

[fhainz]

Könnten wir nicht im "herrmannj/fronthem" repository auch den Treiber und evtl. allgemeingültige widgets in der jeweils aktuellen Version bereitstellen?

Finde ich super. Dann wäre alles an einem Platz. Dokumentieren könnte man das dann im Wiki.

Leider nicht. Habe keine wiki-Rechte.

Du kannst eine Email an einem Admin schicken, der legt dann einen Account für dich an. Siehe hier: http://www.fhemwiki.de/wiki/FHEMWiki:Administratoren

Grüße

[herrmannj]

Könnten wir nicht im "herrmannj/fronthem" repository auch den Treiber und evtl. allgemeingültige widgets in der jeweils aktuellen Version bereitstellen?

Gerne, im Augenblick liegt die angepasste sv Version ja auch nirgendwo jungfräulich. Bernd ist eine gute Quelle, aber da sind eben auch die individuellen Anpassungen drin.

Vlt macht es auch Sinn in dem sv git eine fhem-widget.js zu pflegen. Die kann man ja ohne Überscheidung zusätzlich in die root oder base einbinden und man hätte eine zentrale Anlaufstelle für Erweiterungen. Von Bernd gibt es ja Textinput und select und da kommen bestimmt noch viele dazu.

Dann wäre die widget.js getrennt und damit auch etwas update-sicherer. Dort würde ich vorschlagen nur Fehler zu fixen und zu dokumentieren (wie shifter etc).

vg
jörg

[HCS]

Vlt macht es auch Sinn in dem sv git eine fhem-widget.js zu pflegen. Die kann man ja ohne Überscheidung zusätzlich in die root oder base einbinden und man hätte eine zentrale Anlaufstelle für Erweiterungen. Von Bernd gibt es ja Textinput und select und da kommen bestimmt noch viele dazu.

Das macht Sinn. Ich habe bei mir bis jetzt strikt drauf geachtet, nichts an SV selbst ändern zu müssen. Ist ja nicht so schön, wenn man bei einem SV-Update im Eifer des Gefechts sich seine Änderungen wegbügelt.

Die Idee wäre in Deinem git ein ordner "smartvisu", der, sofern zutrffend, die passende Unterstruktur enthält.
smatvisu
-- driver/
---- io_fhem.js
---- io_fhem.min.js
-- lib/
---- functions_config.php

usw.

Den könnte man sich zu einer SV-Installation einfach draufkopieren.

Kannst Du aber ganz nach Deinen Vorstellungen gestalten, ist nur eine Anregung.

[herrmannj]

jo passt. Und dann nehmen wir die Änderungen an widget.js und css mit rein und ergänzen das um die fhem-widget.js (css) plus evtl widgets wie rtr etc.

vg
jörg

[HCS]

Das klingt nach einem Plan 

[herrmannj]

Du gehst von EINEM zentralen UZSU device in FHEM aus, richtig?

Ich hatte bisher immer gedacht, EIN UZSU READING an das fhem device zu setzen, das ich schalten möchte und EIN ZENTRALES UZSU notify, das auf die uzsu-Readings aller devices reagiert und die entspr. at-Befehle erzeugt oder modifiziert.

Was meinst Du dazu? Zu simpel gedacht?

Alle Zeiten wären im normalen statefile gesichert, keine komplexe Sache, oder?

ja schon, zumindest ein fhem uzsu pro sv uzsu.

Die Schaltzeiten in readings am device zu packen ist nur auf den ersten Blick verlockend:
In so einer uzsu gibt es ja eine variable Anzahl von Zeilen die jeweils wieder verschiedene Schaltzeitpunkte haben (die Wochentage). Das uzsu device müsste erstmal schon das format von sv (hier hash) serialisieren um ein Reading in Textform zu bekommen. Das notify müsste jetzt nicht nur das eine Reading (am device) einzelne Zeiten zerlegen (pro Wochentag), sondern das mit allen uzsu readings am device machen, die ordnen, und könnte dann erst den nächsten Schaltzeitpunkt für das at bestimmen. Ein notify kann das mit Bordmitteln nicht, das muss mit ganz viel perl aufgepimpt werden. Das geht im fhem-uzsu device viel effizienter weil ich mir den Umweg über das Menschen - lesbare reading spare und gleich Maschinen - lesbar bleiben kann, das ist also der deutlich geringere Aufwand.

vg
jörg

[bgewehr]

Die Schaltzeiten in readings am device zu packen ist nur auf den ersten Blick verlockend:
In so einer uzsu gibt es ja eine variable Anzahl von Zeilen die jeweils wieder verschiedene Schaltzeitpunkte haben (die Wochentage). Das uzsu device müsste erstmal schon das format von sv (hier hash) serialisieren um ein Reading in Textform zu bekommen. Das notify müsste jetzt nicht nur das eine Reading (am device) einzelne Zeiten zerlegen (pro Wochentag), sondern das mit allen uzsu readings am device machen, die ordnen, und könnte dann erst den nächsten Schaltzeitpunkt für das at bestimmen. Ein notify kann das mit Bordmitteln nicht, das muss mit ganz viel perl aufgepimpt werden. Das geht im fhem-uzsu device viel effizienter weil ich mir den Umweg über das Menschen - lesbare reading spare und gleich Maschinen - lesbar bleiben kann, das ist also der deutlich geringere Aufwand.

Also: dieser UZSU-Converter funktioniert für speichern und lesen der UZSU-Settings an einem Reading eines fhem-device ohne Anpassung des USZU-Codes in SV:

Code Auswählen Erweitern


###############################################################################
#
# Setreading a device reading using JSON conversion (gadval => reading=decode_json() => setval => encode_json(reading) )
#
###############################################################################

sub UZSU(@)
{
use JSON;

  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')
  {
    $param->{cmd} = 'send';
  }
  if ($param->{cmd} eq 'send')
  {
    $param->{gad} = $gad;
$param->{gadval} = decode_json(main::ReadingsVal($device, $reading, ''));
$param->{gads} = [];
    return undef;
  }
  elsif ($param->{cmd} eq 'rcv')
  {
$gadval = encode_json($gadval);
$gadval =~ s/;/;;/ig;
$param->{result} = main::fhem("setreading $device $reading $gadval");
$param->{results} = [];
    return 'done';
  }
  elsif ($param->{cmd} eq '?')
  {
    return 'usage: UZSU';
  }
  return undef;
}


Das Reading wirft brav seine events in fhem:

Code Auswählen Erweitern


2015-01-31 15:52:36 CUL_HM Roll_EG uzsu: {"active":true,"list":[{"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SU","time":"","value":1,"active":true},{"value":0,"time":"","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE","active":true},{"value":0,"time":"00:00","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH","active":true}]}


und SV kann das alles sauber wieder anzeigen:

Code Auswählen Erweitern


[io.fhem] receiving data: {"cmd":"item","items":["EG_blind_uzsu",{"active":true,"list":[{"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SU","time":"","value":1,"active":true},{"value":0,"time":"","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE","active":true},{"value":0,"time":"00:00","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH","active":true}]}]}


Was jetzt fehlt, ist ein notify, das darauf reagiert und eine custom function in der 99_uzsu.pm, um das perl-Objekt zu verarbeiten.
Erscheint mir nicht so schlimm schwierig, oder?

Bremst mich, sonst mach ich das jetzt...

[herrmannj]

Lass Dich bremsen - oder besser umlenken

Im Prinzip passt ja alles, aber lass uns doch das notify und das at direkt mit in das device nehmen - wo soll der Vorteil sein die alle zu trennen und von Hand zu konfigurieren

Schreib mal noch 3 weitere Zeilen in sv (uzsu) dazu, dann wird das Reading fix breit (das wäre nur optisch).
Für die Maschine würde jetzt die nächste Aufgabe darin bestehen das reading von links nach rechts (oben nach unten) durchzuparsen und daruas den nächsten Schaltzeitpunkt zu ermitteln.

Also: Eintrag #1 lautet 8:00 Di,Mi,Do: ein. Eintrag #2 9:00 Di,Mi,Do: aus. Eintrag #3 7:00 Mo,Sa,So: ein. ... usw
Wir haben jetzt (fiktiv) Montag 5:00 - jetzt muss geparst werden. Geh mal gedanklich davon weg wo (notify, modul etc) der code steht weil unabhängig davon wo ist er ja funktionell gleich.

Du kannst jetzt (ohne wieder über json zu gehen) das direkt auf dem hash im fhem uszu modul machen - das ist einfacher. Btw, ich würde das use JSON unbedingt (!) aus dem converter ruasnehmen - schau mal in den editor, die ganzen json routinen werden jetzt als converter angezeigt.

Geht so (modul):

Code Auswählen Erweitern


package main;
use JSON;

sub makeJSON(@)
{
  return magische_convertierung($);
}

package fronthem;

my $brauche_JSON = main::makeJSON(..);



vg
jörg