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

[herrmannj]

Hallo zusammen,

endlich habe ich fronthem auch bei mir am laufen. An dieser Stelle eine große Dankeschön an "herrmannj & Co" für die brillante Arbeit. Wirklich toll.

Bei mir lief vor der Installation von Fronthem noch der OwServer httpd daemon. Der benutzt lustiger weise ebenfalls port 2121.
Das fiel bei einen telnet auf den Port allerdings nicht sofort auf. Erst als ich ein wget auf den port gemacht habe.
Lustigerweise klappt wenn der OwServer http deamin läuft das "update force ..." auf der Konsole ebenfalls nicht. Den Zusammenhang habe ich aber nicht hergestellt.

Wer also Onewire und Owfs einsetzt sollte vor der Installation prüfen ob port 2121 schon belegt ist. Eine Fehlermeldung das der Port nicht aufgemacht werden kann ist mir weder im Logfile noch in der Konsole aufgefallen.

Viele Grüße,

TomTom

Hallo TomTom,

danke - den Fehlermeldung dazu habe noch auf todo.

2121 scheint der Standard Port beim ows zu sein, sollte fronthem evtl umziehen ... ?

vg
jörg

ps, eine option damit man den port anpassen kann kommt ebenfalls noch.

[herrmannj]

Hallo Jörg,

sieht erst mal sehr gut aus: habe jetzt zweimal von Safari auf Firefox und wieder zurück gewechselt, fhem läuft weiter und die Daten kommen auch sauber an. Top

Grüße

Hi perfekt,

schau mal bitte das Du nicht mit der gleichen ip (gleichzeitig) zwei mal rauf gehst, das wird noch nicht abgefangen (hat aber auch keine ernsten Auswirkungen)

Der Absturz den Du heute morgen hattest entstand in etwas anderer Konstellation:

smartVisu lief und Du hast den Deckel vom NB zu gemacht (danach ca 15-20 min warten). Das wurde in den ersten Versionen von mir nicht richtig ausgewertet und gab den Fehler - soll jetzt beseitigt sein. ( Insgesamt waren die Umstände noch spezieller, daher ist es in der alpha nicht aufgefallen , deswegen teste ich auch gerade noch )

Wer mag - gerne Streßtest (in Bezug auf Verbindung) machen:

NB Deckel zu, mal mit dem Ipad aus dem WLAN raus laufen, wieder ein - flugmodus - das volle Programm.  Das hat einfach den Hintergrund das es Umstände gibt an die man (hier ich ...) beim Schreiben nicht denkt - und das Ding soll ja bullet proof laufen.

Danke vg
jörg

[ftobi]

Hallo Jörg,

Wer mag - gerne Streßtest (in Bezug auf Verbindung) machen:

NB Deckel zu, mal mit dem Ipad aus dem WLAN raus laufen, wieder ein - flugmodus - das volle Programm.  Das hat einfach den Hintergrund das es Umstände gibt an die man (hier ich ...) beim Schreiben nicht denkt - und das Ding soll ja bullet proof laufen.

Danke vg
jörg

hab gestern abend die Seite geöffnet gelassen und klassisch den Notebookdeckel zu gemacht.
Heute früh geöffnet, auch auf ein paar andere Zimmer geklickt, es kamen keine Daten mehr (Domotica Error in der oberen rechten Ecke). Nach nem Seitenrefresh (F5) war alles wieder gut.

Grüße
Tobi

Ergänzung: heute abend den Browser geöffnet, da wurden noch die alten Werte angezeigt. Nach Wechsel in einen anderen Raum wurde der Domotica-Fehler angezeigt, kurze Warte-Pause (schätze ca. 2-4 Sekunden), dann waren die Werte aktualisiert und es ging wieder alles einwandfrei.
Auf dem Android-Tablet, das von heute früh bis jetzt nicht angefasst wurde, wurden direkt nach dem Öffnen die richtigen Werte und ohne Domotica-Fehler angezeigt.

[JoWiemann]

ja stimmt, die im Modul ist auch nicht aktuell. Das hängt mit dem fhem js update zusammen. Rudi hat den loader aber scheinbar so gefixt das ich den den jquery loader im editor anpassen kann - dann sollte das weg sein.

können wir beide das kurz testen ?

vg
jörg

KÖnen wir gerne machen.

Grüße Jörg

[justme1968]

kurz zu den hue: um den on/off zustand zuverlässig zu ermitteln sollte man das onoff oder das pct reading verwenden und nicht state.

in onoff steht 0 oder 1 drin.

in pct 0-100 wobei 0 tatsächlich aus ist.

gruss
  andre

[bgewehr]

@Jörg: Meinst Du ich sollte den genRegExp Converter auf beliebig viele Wertepaare erweitern? Das müssen ja nicht immer 2:2 sein...

Andere Frage: was hältst Du von einem JSONList Converter, dem ich beliebig viele Readings mitgeben kann, damit er die Werte dieser Readings als JSON Liste an SV übergibt? Wäre sicher ganz praktisch für so Dropdown select UI Elemente...


Gesendet von iPhone mit Tapatalk

[daduke]

kurz zu den hue: um den on/off zustand zuverlässig zu ermitteln sollte man das onoff oder das pct reading verwenden und nicht state.

in onoff steht 0 oder 1 drin.

in pct 0-100 wobei 0 tatsächlich aus ist.

gruss
  andre

Danke Andre, leider hat das in meinen Tests nicht funktioniert, da ich keine Kombination mit onoff hinbekomme, in der ich die Lampe dann auch schalten könnte (anstatt nur den Status anzuzeigen). Vermutlich liegt es daran, dass ja onoff 0 oder 1 will, also connector Direct, aber dann klappt das 'set hue 1' nicht, was ja erst durch connector OnOff zu 'set hue on' wird. Oder verstehe ich etwas grundsätzlich falsch?

danke,
-Christian

[MartinMuc]

Ich hab mir damit geholfen

attr Lampe userReadings status {if(ReadingsVal($name,"onoff",0)==0) {"off"} else {"on"}}

[herrmannj]

Danke Andre, leider hat das in meinen Tests nicht funktioniert, da ich keine Kombination mit onoff hinbekomme, in der ich die Lampe dann auch schalten könnte (anstatt nur den Status anzuzeigen). Vermutlich liegt es daran, dass ja onoff 0 oder 1 will, also connector Direct, aber dann klappt das 'set hue 1' nicht, was ja erst durch connector OnOff zu 'set hue on' wird. Oder verstehe ich etwas grundsätzlich falsch?

danke,
-Christian

Hi Christian,

bin jetzt nicht Andre aber Andre kann vmtl auch wenig zum converter sagen. Verstehe ich richtig ? :  es würde gehen wenn der (ein) converter am "Eingang" (reading/event 'onoff') die 0/1 durch reichen würde, am Ausgang aber die 0/1 von sv in 'off' und 'on' wandeln würde ?

Wenn ja, kein Problem: du könntest Dir dazu die 99_fronthemUtils.pm aus laden und das schnell so reinklöppeln (ungetestet).

Reading ist dann "onoff" / Set ist "hue". Einfügen in die 99... sutdown restart und dann ist der converter  als "PhillipsHueOnOff" sichtbar.

vg
jörg

Code Auswählen Erweitern

sub PhillipsHueOnOff(@)
{
  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, '0');
    $param->{cmd} = 'send';
  }
  if ($param->{cmd} eq 'send')
  {
    $param->{gad} = $gad;
$param->{gadval} = $even;
$param->{gads} = [];
    return undef;
  }
  elsif ($param->{cmd} eq 'rcv')
  {
$param->{result} = ($gadval)?'on':'off';
$param->{results} = [];
    return undef;
  }
  elsif ($param->{cmd} eq '?')
  {
    return 'usage: AnAus';
  }
  return undef;
}

edith:
sorry martin, überschnitten: Deins ist natürlich kürzer 

[daduke]

Ihr habt natürlich recht, ABER: am einfachsten ist es, OnOff so umzudrehen, wie ich gestern vorgeschlagen habe, dann muss man nämlich weder einen speziellen Konverter schreiben noch FHEM-intern states umdefinieren. Ich bleibe wohl einfach dabei. Wenn Andres Lösung einfach gegangen wäre, ok, aber so... 

Gruß,
-Christian

[herrmannj]

@Jörg: Meinst Du ich sollte den genRegExp Converter auf beliebig viele Wertepaare erweitern? Das müssen ja nicht immer 2:2 sein...

Andere Frage: was hältst Du von einem JSONList Converter, dem ich beliebig viele Readings mitgeben kann, damit er die Werte dieser Readings als JSON Liste an SV übergibt? Wäre sicher ganz praktisch für so Dropdown select UI Elemente...


Gesendet von iPhone mit Tapatalk

Hi Bernd,

sorry, bin erst gestern Abend zur uzsu gekommen, mit folgendem Stand:

den JSON weg halte (generell) für falsch weil: JSON ist ja nur der Transportweg - normal (hatte mich auch bei der uzsu schon gewundert) sollten wir mit dem Transport gar nicht dealen.

Wenn wir listen (select, wobei: kennst Du ein widget dazu?) brauchen sollten wir uns direkt Listen vornehmen, was für die Lichtszene via dummy ja auch gut funktioniert. Ansonsten schreib mal bitte den use case, ich schau mal.

USZU (sollgten wir einem extra thread weitermachen):

Da gilt das auch. Man braucht dort keinen Umweg über JSON. Ich habe im Anhang einen leicht modifizierten dummy, der hat den UZSU converter gleich eingebaut.   Die Daten kommen auch bei direct im richtigen Format  auf einem dummy an (perl hash) - nur der dummy weiß eben nichts damit anzufangen.

In den POC im Anhang wird ein reading Test erzeugt wo einfach der befehl (0,1 / 'on'/'off') und die Zeit verkettet wird - wie gesagt, nur demo.

Die gesamte Logik um tatsächlich zu schalten (im Prinzip ein eingebautes at), die Logik zum speichern auf Platte sowie der Zugang über fhemweb / floorplan etc müssen logischerweise noch. Ich weiß jetzt nicht ob Andre mit liest. Die Daten (hash Dumper) sehen so aus:

Code Auswählen Erweitern

$VAR1 = {
          'active' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
          'list' => [
                      {
                        'value' => 1,
                        'time' => '10:00',
                        'rrule' => 'FREQ=WEEKLY;BYDAY=MO,TU,FR',
                        'active' => $VAR1->{'active'}
                      }
                    ]
        };

wobei "list" eben beliebig viele, unterschiedliche, Einträge enthalten kann.
Value ist der Schaltbefehl, der ist konfigurierbar und kann auch "on" "off" | "laut" "leise" - whatever sein. Hier würde jetzt Mo, Do, Fr um 10:00 einen "1" anstehen.

Vorschlag:
ich lasse die Daten intern in einem $hash (keine Readings, die können später dazu). @andre: schau mal bitte ob Du damit, später für das widget, arbeiten kannst. Sonst gern Info.
Speicher: Die Zeiten in die fhem.cfg zu speichern wird mMn schwer weil schnell lange Strukturen zusammenkommen die ich dann in ein reading qeutschen müsste. Ich würde über eine sep Zeitdatei (pro uszu) gehen. Frage: in welches Verzeichnis ?

Zum konkreten Schalten: entweder man gibt der uzsu in der def ein device mit, dann schaltet die direkt mit dem konfigurierten Befehl
- und -
der state der uszu entspricht dem konfigurierten Befehl. Am Beispiel oben würde also am Montag, um 10:00, die fhem uszu auf state 1 gehen - dann kann ich mit notify arbeiten.

Wenn das für alle passt würde ich gegen Ende der Woche damit weitermachen und die Zeitlogik implementieren - dann wäre sie über sv einsatzbereit. Für fhemweb/floorplan bäuchte es das widget oder ein anderes geeignetes Bedienkonzept.

ideen, Anregungen, Vorschläge, Einwände ?

vg
jörg

[herrmannj]

Ihr habt natürlich recht, ABER: am einfachsten ist es, OnOff so umzudrehen, wie ich gestern vorgeschlagen habe, dann muss man nämlich weder einen speziellen Konverter schreiben noch FHEM-intern states umdefinieren. Ich bleibe wohl einfach dabei. Wenn Andres Lösung einfach gegangen wäre, ok, aber so... 

Gruß,
-Christian

na klar, gerne. Wir jammern ja auch auf hohem Niveau - die Frage ist immerhin nicht ob es geht, sondern welche der zahlreichen Möglichkeiten schön ist. Bin sicher es könnte schlimmer kommen 

vg
jörg

[justme1968]

ein hash mit den schaltzeiten ist kein problem. ein reading (oder auch ein event ohne reading) das es eine änderung gab wäre aber schön

wenn die schaltzeiten nicht in readings stehen (wegen des namens problems) dann muss ich sie auf einem anderen weg holen. das kann ein get sein (muss ich aber dann wieder parsen und aufbereiten bevor ich es weiter verarbeite) oder gleich ein hash in einem dokumentierten format.

ich weiss noch nicht genau ob ich das ganze erst mal auf fhem seite vorbereite und dann ans frontend schicke oder ob ich gleich alles per json ans frontend schicke und dort direkt verwende. ersteres ist einfacher zu debuggen bei letzterem lässt sich eventuell mehr von sv wiederverwenden.

ich als 'anwender' fände es schön wenn bei time nicht nur eine feste zeit sondern auch symbolisch etwas relativ zum sonnenauf- und -untergang stehen kann. wenn hier nur die 'fertige' zeit steht kann ich im frontend nicht mehr darstellen das es eigentlich relativ zur sonnenauf- oder -untergang steht.

es gibt in fhem jeweils eine FileRead und FileWrite funktion mit der aus dem modul beliebige daten auf platte (oder in die configDb) geschrieben werden können. das modul kann direkt bei einer änderung speichern oder sich an global:SAVE hängen. als format für dieses file ist frei. man könnte z.b. den obigen hash zum speichern per Data::Dumper serialisieren und beim einlesen per eval wieder deserialisieren. ein beispiel dafür gibt es im LightScene modul (noch ohne FileRead/FileWrite sondern noch direkt mit perl file io).

wie wäre es sich für die möglichkeiten bei der wiederholung mal ical anzuschauen?

gruss
  andre

ps: LightScene ist für licht (und andere) szenen besser als dummy

apps: ein eigener thread für die uzsu wäre gut.

[herrmannj]

ein hash mit den schaltzeiten ist kein problem. ein reading (oder auch ein event ohne reading) das es eine änderung gab wäre aber schön

check!

wenn die schaltzeiten nicht in readings stehen (wegen des namens problems) dann muss ich sie auf einem anderen weg holen. das kann ein get sein (muss ich aber dann wieder parsen und aufbereiten bevor ich es weiter verarbeite) oder gleich ein hash in einem dokumentierten format.

da richte ich mich nach Dir. Ich habe einfach keine gute idee wie ich das in readings abbilde. get und dokumentierter hash geht beides ohne prob - letzteres vmtl charmanter.

ich weiss noch nicht genau ob ich das ganze erst mal auf fhem seite vorbereite und dann ans frontend schicke oder ob ich gleich alles per json ans frontend schicke und dort direkt verwende. ersteres ist einfacher zu debuggen bei letzterem lässt sich eventuell mehr von sv wiederverwenden.

your choice, auf sv brauchst Du keine Rücksicht zu nehmen, da existiert widget und transport ja ohnehin.

ich als 'anwender' fände es schön wenn bei time nicht nur eine feste zeit sondern auch symbolisch etwas relativ zum sonnenauf- und -untergang stehen kann. wenn hier nur die 'fertige' zeit steht kann ich im frontend nicht mehr darstellen das es eigentlich relativ zur sonnenauf- oder -untergang steht.

lass mal im ersten Wurf ohne machen - die Einfachheit ist ja ein charmanter Faktor und die Lösung muss ja nicht jeden erdenklichen Fall erschlagen, sr un ss rüsten wir einfach bei Bedarf nach - oder machen dafür auch was einfaches.

es gibt in fhem jeweils eine FileRead und FileWrite funktion mit der aus dem modul beliebige daten auf platte (oder in die configDb) geschrieben werden können. das modul kann direkt bei einer änderung speichern oder sich an global:SAVE hängen. als format für dieses file ist frei. man könnte z.b. den obigen hash zum speichern per Data::Dumper serialisieren und beim einlesen per eval wieder deserialisieren. ein beispiel dafür gibt es im LightScene modul (noch ohne FileRead/FileWrite sondern noch direkt mit perl file io).
wie wäre es sich für die möglichkeiten bei der wiederholung mal ical anzuschauen?

cool, kannte ich nicht. Schau ich mir an, hab nämlich auch schon darüber nachgedacht wie cfg-db user das mit der fronthem cfg machen - da passt das zusätzlich.

vg
jörg

ps: LightScene ist für licht (und andere) szenen besser als dummy

I know - für mich (individuell) fahre ich mich dem dummy gut weil der (bei mir) mit automatiken, presence und co verknüpft ist.

apps: ein eigener thread für die uzsu wäre gut.

yupp, bleiben wir in frontends damit ?

[eldrik]

mit Sicherheit wurde die Frage in dem 55 Seiten langen Thread schon gestellt, aber an welcher Stelle kann ich denn aktiv etwas editieren? Wo finde ich diese GAD`s 

Ich habe auf meine mac mini

- einen Apache installiert, dort wie im wiki beschrieben Smartvisu installiert, welches auch mit der korrekten Startseite erscheint.

- Die notwendigen Perl Module installiert

- fronthem per update force installiert

- fronthem definiert STATE

- fronthemDevice für ein iPad und ein MBP definiert

Gehe ich mit den Clients auf http://server/smartvisu/index.php wird in FHEM auch brav connected bei den Clients angezeigt

Aber an welcher Stelle kann ich jetzt Dinge mit einem Editor bearbeiten?

Eine config.ini habe ich z.B. nach meiner Installation nicht im Hauptverzeichnis von sv gefunden, dass manuelle anlegen und füllen mit Angaben, welche ich am Anfang des Threads gefunden habe:

Code Auswählen Erweitern

[clients]
10.0.81.254 = 'iPad'
10.0.81.248 = 'mbp'
[client:iPad]
title = 'Fhem'
cache = false
animation = false
driver_realtime = true
pages = 'fhem'
design = 'night'
driver_address = '10.0.81.60'
[client:mbp]
title = 'Fhem'
cache = false
animation = false
driver_realtime = true
pages = 'fhem'
design = 'night'
driver_address = '10.0.81.60'

hat keinen Effekt auf den Eingangsbildschirm den meine Clients beim verbinden mit sv haben. (dort wird weiterhin ein Demo Haus angezeigt)

Greetz
Eldrik